MySQL 9.0 版本说明
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;假设查询结果表明是线程 2 持有互斥锁 A，如
mutex_instances.LOCKED_BY_THREAD_ID中所示。您可以查看线程 2 正在做什么
SELECT * FROM performance_schema.events_waits_current WHERE THREAD_ID = thread_2;