25.19 使用性能模式诊断问题
Performance Schema 是一种工具，它通过进行实际测量而不是“疯狂的猜测”来帮助 DBA 进行性能调整。本节演示了为此目的使用性能模式的一些方法。这里的讨论依赖于事件过滤的使用，在第 25.4.2 节“性能模式事件过滤”中进行了描述。
以下示例提供了一种可用于分析可重复问题的方法，例如调查性能瓶颈。首先，您应该有一个可重复的用例，其中性能被认为“太慢”并且需要优化，并且应该启用所有检测(根本不进行预过滤)。
-
运行用例。
-
使用性能架构 table，分析性能问题的根本原因。该分析将严重依赖于后过滤。
-
对于排除的问题区域，请禁用相应的仪器。例如，如果分析 table 明问题与特定存储引擎中的文件 I/O 不相关，请禁用该引擎的文件 I/O 工具。然后截断历史记录和摘要 table 以删除以前收集的事件。
-
重复步骤 1 的过程。
在每次迭代中，Performance Schema 输出(尤其是events_waits_history_longtable)将包含越来越少的由不重要的工具引起的“噪声”，并且鉴于此 table 具有固定的大小，将包含与问题分析相关的越来越多的数据在眼前。
在每次迭代中，调查都应越来越接近问题的根本原因，因为“信噪比”将提高，从而使分析更加容易。
-
一旦确定了性能瓶颈的根本原因，请采取适当的纠正措施，例如：
-
调整服务器参数(缓存大小，内存等)。
-
通过不同的方式调整查询，
-
调整数据库模式(table，索引等)。
-
调整代码(仅适用于存储引擎或服务器开发人员)。
-
从步骤 1 重新开始，以查看更改对性能的影响。
mutex_instances.LOCKED_BY_THREAD_ID和rwlock_instances.WRITE_LOCKED_BY_THREAD_ID列对于调查性能瓶颈或僵局非常重要。可以通过 Performance Schema 工具来实现此目的，如下所示：
-
假设线程 1 处于 await 互斥的状态。
-
您可以确定线程正在 await 什么：
SELECT * FROM performance_schema.events_waits_current
WHERE THREAD_ID = thread_1;
说查询结果标识线程正在 awaitevents_waits_current.OBJECT_INSTANCE_BEGIN中找到的互斥锁 A。
- 您可以确定哪个线程持有互斥锁 A：
SELECT * FROM performance_schema.mutex_instances
WHERE OBJECT_INSTANCE_BEGIN = mutex_A;
说查询结果 table 明它是持有 MutexA 的线程 2，如mutex_instances.LOCKED_BY_THREAD_ID所示。
- 您可以看到线程 2 在做什么：
SELECT * FROM performance_schema.events_waits_current
WHERE THREAD_ID = thread_2;