参考官方文档：
https://dev.mysql.com/doc/refman/5.7/en/innodb-performance-schema.html



本节简要介绍InnoDB与Performance Schema的集成。


要使用此功能来检查InnoDB性能：

• 您必须大致熟悉如何使用性能架构功能。 例如，您应该知道如何启用设施和使用者，以及如何查询performance_schema表以检索数据。
• 您应该熟悉InnoDB可用的性能模式工具。 要查看与InnoDB相关的设施，您可以在setup_instruments表中查询包含'innodb'的仪器名称。

mysql> SELECT * FROM setup_instruments WHERE NAME LIKE '%innodb%';



有关已检测的InnoDB对象的其他信息，可以查询性能模式实例表，这些表提供有关已检测对象的其他信息。 与InnoDB相关的实例表包括：

• mutex_instances表
• rwlock_instances表
• cond_instances表
• file_instances表

注意：
与InnoDB缓冲池相关的互斥锁和RW锁不包含在此coverage中; 这同样适用于SHOW ENGINE INNODB MUTEX命令的输出。


例如，要查看执行文件I/O检测时性能模式所见的已检测InnoDB文件对象的信息，可以发出以下查询：


mysql> SELECT * FROM file_instances WHERE EVENT_NAME LIKE '%innodb%'\G

• 您应该熟悉存储InnoDB事件数据的performance_schema表。 与InnoDB相关的活动相关的表格包括：

• 等待事件表，用于存储等待事件。
• Summary 表，随时间提供已终止事件的聚合信息。 摘要表包括文件I/O summary table，它汇总了有关I/O操作的信息。
• Stage Event表，用于存储InnoDB ALTER TABLE和缓冲池加载操作的事件数据。

如果您只对与InnoDB相关的对象感兴趣，请在查询这些表时使用子句WHERE EVENT_NAME LIKE'％innodb％'或WHERE NAME LIKE'％innodb％'（根据需要）。




14.16.1 使用性能模式监控InnoDB表的ALTER TABLE进度


您可以使用Performance Schema监视InnoDB表的ALTER TABLE进度。


有七个阶段事件代表ALTER TABLE的不同阶段。 每个阶段事件报告整个ALTER TABLE操作的运行总计WORK_COMPLETED和WORK_ESTIMATED，因为它在不同的阶段中进行。 WORK_ESTIMATED是使用一个公式计算的，该公式考虑了ALTER TABLE执行的所有工作，并且可以在ALTER TABLE处理期间进行修改。 WORK_COMPLETED和WORK_ESTIMATED值是ALTER TABLE执行的所有工作的抽象表示。


按发生顺序，ALTER TABLE阶段事件包括：

• stage/innodb/alter table（读取PK和内部排序）：当ALTER TABLE处于读取 - 主键 - 阶段时，此阶段处于活动状态。 它以WORK_COMPLETED = 0和WORK_ESTIMATED设置为主键中的估计页数开始。 完成阶段后，WORK_ESTIMATED将更新为主键中的实际页数。
• stage/innodb/alter table（merge sort）：对ALTER TABLE操作添加的每个索引重复此阶段。
• stage/innodb/alter table（insert）：对ALTER TABLE操作添加的每个索引重复此阶段。
• stage/innodb/alter table（ log apply index）：此阶段包括ALTER TABLE运行时生成的DML日志的应用。
• stage/innodb/alter table（flush）：在此阶段开始之前，根据刷新列表的长度，使用更准确的估计更新WORK_ESTIMATED。
• stage/innodb/alter table（ log apply table）：此阶段包括ALTER TABLE运行时生成的并发DML日志的应用。 此阶段的持续时间取决于表发生更改的extent。 如果没有在表上运行并发DML，则此阶段是即时的。
• stage/innodb/alter table（end）：包括刷新阶段后出现的任何剩余工作，例如重新应用ALTER TABLE运行时在表上执行的DML。

注意：
InnoDB ALTER TABLE阶段事件当前不考虑添加空间索引。


使用性能方案的ALTER TABLE监控的例子


以下示例演示如何启用stage/innodb/alter table％stage事件工具和相关的使用者表来监视ALTER TABLE进度。

• 启用stage/innodb/alter％设施：

mysql> UPDATE setup_instruments SET ENABLED = 'YES' WHERE NAME LIKE 'stage/innodb/alter%';

• 启用stage事件使用者表，其中包括events_stages_current，events_stages_history和events_stages_history_long。

mysql> UPDATE setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%stages%';

• 运行ALTER TABLE操作。 在此示例中，将middle_name列添加到employees示例数据库的employees表中。

mysql> ALTER TABLE employees.employees ADD COLUMN middle_name varchar(14) AFTER first_name;

• 通过查询Performance Schema events_stages_current表来检查ALTER TABLE操作的进度。 显示的阶段事件根据当前正在进行的ALTER TABLE阶段而有所不同。 WORK_COMPLETED列显示已完成的工作。 WORK_ESTIMATED列提供剩余工作的估计值。

mysql> SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED FROM events_stages_current;



如果ALTER TABLE操作已完成，则events_stages_current表返回一个空集。 在这种情况下，您可以检查events_stages_history表以查看已完成操作的事件数据。 例如：


mysql> SELECT EVENT_NAME, WORK_COMPLETED, WORK_ESTIMATED FROM events_stages_history;

如上所示，在ALTER TABLE处理期间修改了WORK_ESTIMATED值。 完成初始阶段后的估计工作是1213.当ALTER TABLE处理完成时，WORK_ESTIMATED设置为实际值，即1981。




14.16.2 使用性能方案监控InnoDB Mutex等待


mutex是代码中使用的同步机制，用于强制在给定时间只有一个线程可以访问公共资源。 当在服务器中执行的两个或多个线程需要访问相同的资源时，线程相互竞争。 获取互斥锁上的锁的第一个线程会导致其他线程等待，直到释放锁。




对于已被实施的InnoDB互斥锁，可以使用性能方案监视互斥等待。 例如，在Performance Schema表中收集的等待事件数据可以帮助识别具有最多等待或最长总等待时间的互斥锁


以下示例演示了如何启用InnoDB互斥等待工具，如何启用关联的使用者以及如何查询等待事件数据。


1.要查看可用的InnoDB互斥等待设施，请查询Performance Schema setup_instruments表，如下所示。 默认情况下，所有InnoDB互斥等待设施都被禁用。


mysql> SELECT * FROM performance_schema.setup_instruments WHERE NAME LIKE '%wait/synch/mutex/innodb%';


2.某些InnoDB互斥锁实例是在服务器启动时创建的，只有在服务器启动时也启用了关联的设施时才会进行检测。 要确保检测并启用所有InnoDB互斥锁实例，请将以下性能架构设施规则添加到MySQL配置文件中：




performance-schema-instrument='wait/synch/mutex/innodb/%=ON'




如果您不需要所有InnoDB互斥锁的等待事件数据，则可以通过向MySQL配置文件添加其他性能方案设施规则来禁用特定仪器。 例如，要禁用与全文搜索相关的InnoDB互斥等待事件工具，请添加以下规则：


performance-schema-instrument='wait/synch/mutex/innodb/fts%=OFF'



注意：
具有较长前缀的规则（例如wait / synch / mutex / innodb / fts％）优先于具有较短前缀的规则，例如wait / synch / mutex / innodb /％。



将performance-schema-instrument规则添加到配置文件后，重新启动服务器。 除了与全文搜索相关的那些之外，所有InnoDB互斥锁都被启用。 要验证，请查询setup_instruments表。 对于您启用的工具，ENABLED和TIMED列应设置为YES。


mysql> SELECT * FROM performance_schema.setup_instruments WHERE NAME LIKE '%wait/synch/mutex/innodb%';


3.通过更新setup_consumers表启用等待事件使用者。 默认情况下禁用等待事件使用者。


mysql> UPDATE performance_schema.setup_consumers SET enabled = 'YES' WHERE name like 'events_waits%';

Query OK, 3 rows affected (0.00 sec) Rows matched: 3 Changed: 3 Warnings: 0


您可以通过查询setup_consumers表来验证是否启用了等待事件 consumers 。 应该启用events_waits_current，events_waits_history和events_waits_history_long consumers 。


mysql> SELECT * FROM performance_schema.setup_consumers;



4.启用工具和使用者后，运行要监视的工作负载。 在此示例中，mysqlslap加载仿真客户端用于模拟工作负载。


shell> ./mysqlslap --auto-generate-sql --concurrency=100 --iterations=10 --number-of-queries=1000 --number-char-cols=6 --number-int-cols=6;


5.查询等待事件数据。 在此示例中，从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

汇总的定时等待事件的最长等待时间。




以下查询返回设施名称（EVENT_NAME），等待事件数（COUNT_STAR）以及该设施事件的总等待时间（SUM_TIMER_WAIT）。 因为默认情况下等待时间以皮秒（万亿分之一秒）为单位，所以等待时间除以1000000000以显示等待时间（以毫秒为单位）。 数据按汇总等待事件的数量（COUNT_STAR）降序显示。 您可以调整ORDER BY子句以按总等待时间对数据进行排序。


mysql> SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT/1000000000 SUM_TIMER_WAIT_MS FROM performance_schema.events_waits_summary_global_by_event_name WHERE SUM_TIMER_WAIT > 0 AND EVENT_NAME LIKE 'wait/synch/mutex/innodb/%' ORDER BY COUNT_STAR DESC;




注意:
前面的结果集包括在启动过程中产生的等待事件数据。 要排除此数据，可以在启动后和运行工作负载之前立即截断events_waits_summary_global_by_event_name表。 但是，截断操作本身可能会产生可忽略不计的等待事件数据。


mysql> TRUNCATE performance_schema.events_waits_summary_global_by_event_name;