MySQL 8.3 Release Notes
性能模式是一个工具，帮助 DBA 通过实际测量来进行性能调整，而不是进行“猜测”。本节展示了使用性能模式进行性能调整的一些方法。本讨论依赖于事件过滤的使用，该方法在 第 29.4.2 节“性能模式事件过滤”中进行了描述。
以下示例提供了一种方法来分析可重复的问题，例如调查性能瓶颈。首先，您应该有一个可重复的用例，其中性能被认为“太慢”并需要优化，并且您应该启用所有仪器（不进行预过滤）。
-
运行用例。
-
使用性能模式表，分析性能问题的根本原因。该分析高度依赖后期过滤。
-
对于排除的问题领域，禁用相应的仪器。例如，如果分析表明问题不相关于某个存储引擎的文件 I/O，则禁用该引擎的文件 I/O 仪器。然后，截断历史记录和汇总表以删除之前收集的事件。
-
重复步骤 1。
在每次迭代中，性能模式的输出，特别是
events_waits_history_long表，包含越来越少的“噪音”，由非重要仪器引起，并且由于该表具有固定大小，因此包含越来越多与问题分析相关的数据。在每次迭代中，调查应该越来越接近问题的根本原因，因为“信号/噪音”比率改善，使分析变得更容易。
-
一旦确定了性能瓶颈的根本原因，就采取相应的纠正措施，例如：
-
调整服务器参数（缓存大小、内存等）。
-
通过编写查询的不同方式来调整查询。
-
调整数据库模式（表、索引等）。
-
调整代码（这仅适用于存储引擎或服务器开发人员）。
-
-
从步骤 1 开始，以查看更改对性能的影响。
列 mutex_instances.LOCKED_BY_THREAD_ID 和 rwlock_instances.WRITE_LOCKED_BY_THREAD_ID 对于调查性能瓶颈或死锁非常重要。这是通过性能模式仪器实现的：
-
假设线程 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;