MySQL的performance_schema是运行在较低级别的用于监控MySQL Server运行过程中的资源消耗、资源等待等情况的一个功能特性，它具有以下特点。

• performance_schema提供了一种在数据库运行时实时检查Server内部执行情况的方法。performance_schema数据库中的表使用performance_schema存储引擎。该数据库主要关注数据库运行过程中的性能相关数据，与information_schema不同，information_schema主要关注Server运行过程中的元数据信息。
• performance_schema通过监视Server的事件来实现监视其内部执行情况，“事件”就是在Server内部活动中所做的任何事情以及对应的时间消耗，利用这些信息来判断Server中的相关资源被消耗在哪里。一般来说，事件可以是函数调用、操作系统的等待、SQL语句执行的阶段[如SQL语句执行过程中的parsing（解析）或sorting（排序）阶段]或者整个SQL语句的集合。采集事件可以方便地提供Server中的相关存储引擎对磁盘文件、表I/O、表锁等资源的同步调用信息。
• performance_schema中的事件与写入binlog中的事件（描述数据修改的事件）、事件计划调度程序（这是一种存储程序）的事件不同，该事件记录的是Server执行某些活动时对某些资源的消耗、耗时以及这些活动执行的次数等情况。
• performance_schema中的事件只被记录在本地Server的performance_schema中，其表中数据发生变化时不会被写入binlog中，也不会通过复制机制被复制到其他Server中。
• 当前活跃事件、历史事件和事件摘要相关表中记录的信息，能提供某个事件的执行次数、使用时长，进而可用于分析与某个特定线程、特定对象（如mutex或file）相关联的活动。
• performance_schema存储引擎使用Server源代码中的“检测点”来实现事件数据的收集。对于performance_schema实现机制本身的代码没有相关的单独线程来检测，这与其他功能（如复制或事件计划程序）不同。
• 收集到的事件数据被存储在performance_schema数据库的表中。对于这些表可以使用SELECT语句查询，也可以使用SQL语句更新performance_schema数据库中的表记录（比如动态修改performance_schema的以“setup_”开头的配置表，但要注意，配置表的更改会立即生效，这会影响数据收集）。
• performance_schema的表中数据不会持久化存储在磁盘中，而是保存在内存中，一旦服务器重启，这些数据就会丢失（包括配置表在内的整个performance_schema下的所有数据）。● 对于MySQL支持的所有平台中的事件监控功能都可用，但不同平台中用于统计事件时间开销的计时器类型可能会有所差异。

performance_schema实现机制遵循以下设计目标。

• 启用performance_schema不会导致Server的行为发生变化。例如，它不会改变线程调度机制，不会导致查询执行计划（如EXPLAIN）发生变化。
• 启用performance_schema之后，Server会持续不间断地监测，开销很小，不会导致Server不可用。
• 在performance_schema实现机制中没有增加新的关键字或语句，解析器不会发生变化。
• 即使performance_schema的监测机制在内部对某事件执行监测失败，也不会影响Server正常运行。
• 如果在开始收集事件数据时碰到有其他线程正在针对这些事件信息进行查询，那么会优先执行事件数据的收集，因为事件数据的收集是一个持续不断的过程，而检索（查询）这些事件信息仅仅是在需要查看时才进行的。也可能某些事件信息永远都不会被检索。
• 如果需要，则可以很容易添加新的instruments（事件采集配置项）监测点。
• instruments代码版本化：如果instruments代码发生了变更，那么旧的instruments代码还可以继续工作。

注意：MySQL sys schema是一组对象（包括相关的视图、存储过程和函数），可以方便地访问performance_schema收集的数据，同时检索的数据可读性也更高（例如：performance_schema中的时间单位是p（s皮秒），经过sys schema查询时会转换为可读的us、ms、s、min、hour、day等单位），sys schema在MySQL 5.7.x版本中默认安装。

摘自《千金良方：MySQL性能优化金字塔法则 4.1》