使用性能模式诊断问题

Performance Schema是一种工具，它通过进行实际测量而不是“疯狂的猜测”来帮助DBA进行性能调整。”这一节演示了为此目的使用性能模式的一些方法。这里的讨论依赖于事件过滤的使用，“性能模式事件过滤”中对此进行了描述。

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

1. 运行用例。
2. 使用性能架构表，分析性能问题的根本原因。该分析将严重依赖于后过滤。
3. 对于排除的问题区域，请禁用相应的仪器。例如，如果分析表明问题与特定存储引擎中的文件I / O不相关，请禁用该引擎的文件I / O工具。然后截断历史记录和摘要表以删除以前收集的事件。

4. 重复步骤1的过程。

   在每次迭代中，“性能模式”输出（尤其是events_waits_history_long表）将包含越来越少的由不重要的仪器引起的“噪声”，并且鉴于此表具有固定的大小，因此将包含与问题分析相关的越来越多的数据。手。

   在每次迭代中，随着“信噪比”的提高，调查应越来越接近问题的根本原因，从而使分析更加容易。

5. 一旦确定了性能瓶颈的根本原因，请采取适当的纠正措施，例如：

   • 调整服务器参数（高速缓存大小，内存等）。
   • 通过不同的方式调整查询，
   • 调整数据库模式（表，索引等）。
   • 调整代码（仅适用于存储引擎或服务器开发人员）。
6. 从步骤1重新开始，以参见更改对性能的影响。

在mutex_instances.LOCKED_BY_THREAD_ID与rwlock_instances.WRITE_LOCKED_BY_THREAD_ID列调查性能瓶颈或死锁非常重要的。可以通过Performance Schema工具来实现此目的，如下所示：

1. 假设线程1处于等待互斥的状态。

2. 您可以确定线程正在等待什么：

   SELECT * FROM performance_schema.events_waits_current
   WHERE THREAD_ID = thread_1;
   

   假设查询结果标识该线程正在等待互斥体A（在中找到）events_waits_current.OBJECT_INSTANCE_BEGIN。

3. 您可以确定哪个线程持有互斥量A：

   SELECT * FROM performance_schema.mutex_instances
   WHERE OBJECT_INSTANCE_BEGIN = mutex_A;
   

   假设查询结果表明它是持有互斥锁A的线程2，如中所找到mutex_instances.LOCKED_BY_THREAD_ID。

4. 您可以看到线程2在做什么：

   SELECT * FROM performance_schema.events_waits_current
   WHERE THREAD_ID = thread_2;