MySQL 8.4 Release Notes
29.19 使用 Performance Schema 识诊问题
性能_schema 是一种工具，帮助 DBA 进行性能调优，通过实时测量而不是 “盲猜。” 本节将展示一些使用性能_schema 的方法。这里的讨论依赖于事件过滤，这在 第 29.4.2 节“性能_schema 事件过滤” 中有描述。
以下是一个方法论，用于分析可重复的问题，比如调查性能瓶颈。开始之前，你应该有一个可重复的用例，其中性能被认为 “太慢” 并需要优化，并且启用所有仪器（没有任何预过滤）。
-
运行该用例。
-
使用性能_schema 表格，分析性能问题的根本原因。这项分析主要依赖于后过滤。
-
对于排除在外的问题，禁用相应的仪器。例如，如果分析表明问题与特定存储引擎的文件 I/O 无关，则禁用该引擎的文件 I/O 仪器。然后清空历史和摘要表，以移除之前收集的事件。
-
重复步骤 1。
在每次迭代中，性能_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;说查询结果表明线程正在等待互斥量 A，这在
events_waits_current.OBJECT_INSTANCE_BEGIN中找到。 -
你可以确定哪个线程持有互斥量 A：
SELECT * FROM performance_schema.mutex_instances WHERE OBJECT_INSTANCE_BEGIN = mutex_A;说查询结果表明是线程 2 持有互斥量 A，这在
mutex_instances.LOCKED_BY_THREAD_ID中找到。 -
你可以看到线程 2 在做什么：
SELECT * FROM performance_schema.events_waits_current WHERE THREAD_ID = thread_2;