1.首以mysql5.7版本为例
默认情况下performance_schema功能是开启的。要显式启用或禁用它，需要在performance_schema变量设置为适当值的情况下启动服务器。例如，在服务器my.cnf文件中加入performance_schema=ON，以ubuntu为例如下代码：
1.1实例操作：
1.2参数验证：
注意：当value为ON表示performance_schema已成功初始化并可供使用。相反，当value OFF表示发生了一些错误。检查服务器错误日志以获取有关错误的信息。
1.3performance_schema实现在存储引擎上。
如果此引擎可用就能看到具体SUPPORT值是YES，来看下面的信息内容：
1.4performance_schema的数据字典表存储在 performance_schema数据库中。
通过从INFORMATION_SCHEMA数据库中做SHOW操作，可以获得有关此数据库及其表的结构的信息：
2.performance_schema数据库中的表分组
performance_schema数据库中的表可以根据其中的信息类型进行分组：当前事件，事件历史和摘要，对象实例和设置（配置）信息。以下示例说明了这些表的一些用法。有关每个组中表的详细信息，我们在后面做详细介绍，请耐心看完。
2.1具体操作
2.2查看服务器当前操作
要查看服务器当前正在执行的操作，就需要查 events_waits_current表。它每个线程包含一行，显示每个线程最近监视的事件：
注意：1.EVENT_NAME等待事件表示线程9正在等待80136皮秒来获取锁定 THR_LOCK::mutex表示mysys子系统中的互斥锁 。
2.前几列提供以下信息：
---> ID列指示事件来自哪个线程以及事件编号。
---> EVENT_NAME指示已检测的内容并SOURCE指示哪个源文件包含已检测的代码。
---> 计时器列显示事件开始和停止的时间以及花费的时间。如果一个事件仍在进行中，在 TIMER_END和TIMER_WAIT 值NULL。定时器值是近似值，以皮秒表示。
---> 有关定时器和事件时间收集的信息，下面我会详细介绍。
2.3performance_schema.events_waits_history
performance_schema.events_waits_history历史表包含与当前事件表相同的行，显示服务器最近正在执行的操作。在 events_waits_history和
events_waits_history_long表分别包含每线程最近的10个事件和最近10,000个事件。
2.4events_waits_summary_global_by_event_name
events_waits_summary_global_by_event_name表提供了一段时间内所有事件的汇总信息。该组中的表以不同方式汇总事件数据。要查看哪些程序执行次数最多或者等待时间最长，就需要借助events_waits_summary_global_by_event_name 对COUNT_STAR或者 SUM_TIMER_WAIT列上的表进行排序，这些 表分别对应于 在所有事件上计算的a COUNT(*)或SUM(TIMER_WAIT)值，这个就类似我们在v$session_wait，v$session v$session_longops查等待事件一个道理，以下为具体代码示例：
2.5案例分析
从这个案例可以看到当前数据库是很空闲的，都是idle，后面按照皮秒计算等待事件单元：
2.6
实例表记录了检测的对象类型。当由服务器使用时，检测对象产生事件。这些表提供事件名称和解释性说明或状态信息。例如，该 file_instances表列出了文件I / O操作及其相关文件的工具实例。
2.7
以下是设置表用于配置和显示监视特征。例如， setup_instruments列出可以收集事件的工具集，并显示哪些工具已启用。
2.8
如上显示的ENABLE内容，要控制是否为仪器收集事件，直接update将其ENABLED值设置 为YES或 NO,下面是一个示例代码：
3.performance_schema的配置说明：
3.1
如果在老版本安装的MySQL上没有性能模式就需要在启动服务器后运行mysql_upgrade，以确保 performance_schema数据库存在所有当前状态表。然后重启服务器。需要执行此操作的一个指示是错误日志中存在以下消息：
3.2
要验证服务器是否使用Performance Schema支持构建，执行下面的命令即可。
3.3
可以连接到mysql服务器通过SHOW ENGINES验证：
3.4
PERFORMANCE_SCHEMA性能模式包括几个提供配置信息的系统变量：
3.5
如上图显示，要更改Performance Schema系统变量的值，需要在 my.cnf文件中以更改等待事件的历史记录表的大小。
3.6
performance_schema设置表包含有关监视配置的信息如下几个大类别：
3.7
setup_timers表显示了当前选定的事件计时器，注意从MySQL 5.7.21开始，setup_timers不推荐使用Performance Schema 表，并在MySQL 8.0中被干掉了，下面的脚本中，name表示计时器的模型类别，timer_name就是适用于计时器的类型了。
3.8
如果需要更改类型也是同样的，执行update操作即可.
3.9
setup_instruments表列出了可以收集事件的工具，是否已启用，如果是启用的是否收集时间信息等信息：
3.10
下面这个就比较重要了，performance_schema等待事件的相关数据字典是否启用直接看enabled就可以了：
4.performance_schema表设计规范的一些描述
1
当前事件表。该 events_waits_current表包含每个线程的最新事件。其他类似的表包含事件层次结构的不同级别的当前事件。
2
events_stages_current 用于阶段事件
3
events_statements_current用于语句事件和
4
events_transactions_current用于事务事件
5
历史表。这些表与当前事件表具有相同的结构，但包含更多行。例如，对于等待事件，events_waits_history 表包含每个线程最近的10个事件。
6
events_waits_history_long 包含最近的10,000个事件。语句和事务等历史信息。
7
同样的，要更改历史记录表的大小，还是需要在服务器启动时设置相应的系统变量。例如，要设置等待事件历史记录表的大小，
设置 performance_schema_events_waits_history_size 和 performance_schema_events_waits_history_long_size。
8
汇总表。这些表包含通过事件组聚合的信息，包括已从历史记录表中丢弃的事件。
9
实例表。这些表记录了检测的对象类型。当由服务器使用时，检测对象产生事件。这些表提供事件名称和解释性说明或状态信息。
10
杂项表。这些不属于任何其他表组。
重点
以下为Performance Schema表详细输出：
5.使用performance_schema来监控InnoDB Mutex等待
5.1
5.1工作原理描述：mutex是mysql使用的同步机制，用于强制在给定时间只有一个线程可以访问公共资源。当在服务器中执行的两个或多个线程需要访问相同的资源时，线程相互竞争。获取互斥锁上的锁的第一个线程会导致其他线程等待，直到释放锁。
5.2
5.2对于InnoDB已检测的互斥锁，可以使用性能模式监视互斥等待，例如，在Performance Schema表中收集的等待事件数据可以帮助识别具有最多等待或最长总等待时间的互斥锁。
注意
mysql的mutex和oracle的mutex不一样的,如果你是一个oracle老司机，对于latch或者mutex的本质应该有一定的了解，其实oracle的latch本质是SGA中的一个内存位置和一个用来检查和更改内存位置值的cpu原子操作，当然本篇文章讨论的主题和oracle没什么关系。
5.3
要查看可用的InnoDB互斥等待工具，就需要查询performance_schema的 setup_instruments表，如下所示。InnoDB默认情况下，所有互斥等待仪器都被禁用。
5.4
某些InnoDB互斥锁实例是在服务器启动时创建的，仅在服务器启动时启用了关联的仪器时才会进行检测。要确保InnoDB检测并启用所有互斥锁实例，还需要将以下performance-schema-instrument规则添加 到MySQL配置文件中：
performance-schema-instrument='wait/synch/mutex/innodb/%=ON'
5.5
当然，如果不需要所有InnoDB互斥锁的等待事件数据 ，则可以通过向performance-schema-instrumentMySQL配置文件添加其他规则来禁用特定仪器 。
例如，要禁用 InnoDB与全文搜索相关的互斥等待事件工具，添加以下规则
performance-schema-instrument='wait/synch/mutex/innodb/fts%=OFF'
注意
1.具有较长前缀的规则，例如 wait/synch/mutex/innodb/fts%优先于具有较短前缀的规则，例如 wait/synch/mutex/innodb/%
2.将performance-schema-instrument规则添加 到配置文件后，重新启动服务器。InnoDB除启用与全文搜索相关的互斥锁外，所有 互斥锁均已启用。
要验证，需要再一次查询 setup_instruments表。在 ENABLED与TIMED 列应设置YES。
5.6
更新setup_consumers表启用等待事件使用者
5.7
可以通过查询setup_consumers 表来验证是否启用了等待事件使用者。的events_waits_current， events_waits_history和 events_waits_history_long
消费者应该启用。
5.8
启用仪器和使用者后，运行要监视的工作负载
5.9
查询等待事件数据。在这个例子中，等待事件数据从查询 events_waits_summary_global_by_event_name ，其聚合中找到的数据表 events_waits_current，
events_waits_history和 events_waits_history_long表。数据由事件名称（EVENT_NAME）汇总，事件名称（）是生成事件的工具的名称。汇总数据包括：
💛 COUNT_STAR 汇总等待事件的数量。
💛 SUM_TIMER_WAIT汇总的定时等待事件的总等待时间。
💛 MIN_TIMER_WAIT 汇总的定时等待事件的最短等待时间。
💛 AVG_TIMER_WAIT 汇总的定时等待事件的平均等待时间。
💛 MAX_TIMER_WAIT 汇总的定时等待事件的最长等待时间。
5.10
以下查询等待事件名称（EVENT_NAME），等待事件数（COUNT_STAR）以及该仪器事件的总等待时间（SUM_TIMER_WAIT）。因为默认情况下等待时间以皮秒（万亿分之一秒）为单位，所以等待时间除以1000000000以显示等待时间（以毫秒为单位）。数据按汇总的等待事件数（COUNT_STAR）的降序显示。可以调整ORDER BY子句以按总等待时间对数据进行排序。
6.如何使用performance_schema进行查询分析替代传统的profiles功能
6.1
以下示例为大家演示如何使用performance_schema语句事件和阶段事件来检索与由SHOW PROFILES和SHOW PROFILE语句提供的分析信息相当的数据。
6.2
该setup_actors表可用于限制主机，用户或帐户对历史事件的收集，以减少运行时开销和历史表中收集的数据量。该示例的第一步显示如何将历史事件的收集限制为特定用户。
6.3
performance_schema以皮秒（万亿分之一秒）显示事件定时器信息，以将定时数据标准化为标准单元。在以下示例中，
TIMER_WAIT值除以1000000000000以显示以秒为单位的数据。值也被截断为6位小数，以SHOW PROFILES与 SHOW PROFILE语句相同的格式显示数据。
6.4
将历史事件的集合限制为将运行查询的用户。默认情况下， setup_actors配置为允许所有前台线程的监视和历史事件收集：
6.5
更新setup_actors表中的默认行 以禁用所有前台线程的历史事件收集和监视，并插入一个新行，以便为将运行查询的用户启用监视和历史事件收集.
再一次验证：
6.6
通过更新setup_instruments表确保启用语句和阶段检测 。某些仪器可能已默认启用。
6.7
确保已启用events_statements_*和 events_stages_*使用者。某些消费者可能已默认启用
6.8
运行要分析的语句
6.9
EVENT_ID通过查询events_statements_history_long 表来 识别语句 。此步骤类似于运行 SHOW PROFILES以识别 Query_ID。以下查询生成类似于的输出
SHOW PROFILES。
6.10
查询 events_stages_history_long 表以检索语句的阶段事件。阶段与使用事件嵌套的语句相关联。每个阶段事件记录都有一个NESTING_EVENT_ID包含EVENT_ID父语句的列。
总结
今天内容有点多，和大家分享了performance_schema的特性，如何配置，相关数据字典逻辑关系，对应数据字典如何检索，包括两个performance_schema的案例，希望这篇文档可以帮到各位。
<点亮梦想.拒绝平庸>
长按识别二维码加入600团队
都认认真真看到这了，奖励自己个小心心吧～
