MySQL :: MySQL 8.4 参考手册 :: 29.19 使用 Performance Schema 诊断问题

版本 8.4

8.0 日语

MySQL 8.4 参考手册 / MySQL Performance Schema / 使用 Performance Schema 诊断问题

29.19 使用 Performance Schema 诊断问题

29.19.1 使用 Performance Schema 进行查询分析
29.19.2 获取父事件信息

Performance Schema 是一个工具，它可以帮助 DBA 通过进行真实的测量而不是 “凭空猜测” 来进行性能调优。本节演示了一些使用 Performance Schema 完成此任务的方法。这里讨论的内容依赖于使用事件过滤，这在第 29.4.2 节，“Performance Schema 事件过滤” 中进行了描述。

以下示例提供了一种可以用来分析可重复问题的方法，例如调查性能瓶颈。首先，您应该有一个可重复的用例，其中性能被认为是 “太慢了” 并需要优化，您应该启用所有检测（没有任何预过滤）。

运行用例。
使用 Performance Schema 表分析性能问题的根本原因。此分析很大程度上依赖于后过滤。
对于被排除的问题区域，禁用相应的检测。例如，如果分析表明问题与特定存储引擎中的文件 I/O 无关，请禁用该引擎的文件 I/O 检测。然后截断历史和摘要表以删除先前收集的事件。
重复步骤 1 中的过程。
每次迭代，Performance Schema 输出，特别是 events_waits_history_long 表，包含的由无关紧要的检测导致的 “噪声” 越来越少，并且考虑到该表的大小固定，包含的与分析当前问题相关的数据越来越多。
每次迭代，调查都应该越来越接近问题的根本原因，因为 “信号/噪声” 比例得到改善，使得分析更容易。
一旦确定了性能瓶颈的根本原因，请采取相应的纠正措施，例如
- 调整服务器参数（缓存大小、内存等）。
- 通过不同的方式编写查询来调整查询。
- 调整数据库架构（表、索引等）。
- 调整代码（这仅适用于存储引擎或服务器开发人员）。
从步骤 1 重新开始，查看更改对性能的影响。

mutex_instances.LOCKED_BY_THREAD_ID 和 rwlock_instances.WRITE_LOCKED_BY_THREAD_ID 列对于调查性能瓶颈或死锁至关重要。这是通过 Performance Schema 检测实现的，如下所示

假设线程 1 卡在等待互斥锁。
您可以确定线程在等待什么
```
SELECT * FROM performance_schema.events_waits_current
WHERE THREAD_ID = thread_1;
```
假设查询结果表明线程正在等待 events_waits_current.OBJECT_INSTANCE_BEGIN 中找到的互斥锁 A。
您可以确定哪个线程持有互斥锁 A
```
SELECT * FROM performance_schema.mutex_instances
WHERE OBJECT_INSTANCE_BEGIN = mutex_A;
```
假设查询结果表明是 mutex_instances.LOCKED_BY_THREAD_ID 中找到的线程 2 持有互斥锁 A。

您可以查看线程 2 在做什么

SELECT * FROM performance_schema.events_waits_current
WHERE THREAD_ID = thread_2;