Documentation Home
MySQL 8.0 参考手册  / 第 27 章 MySQL 性能模式  /  27.19 使用性能模式诊断问题

27.19 使用性能模式诊断问题

Performance Schema 是一种工具,可帮助 DBA 通过进行实际测量而不是“胡乱猜测” 来进行性能调优。本节演示为此目的使用性能模式的一些方法。这里的讨论依赖于事件过滤的使用,这在 第 27.4.2 节,“性能模式事件过滤”中有描述。

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

  1. 运行用例。

  2. 使用性能模式表,分析性能问题的根本原因。此分析在很大程度上依赖于后过滤。

  3. 对于排除的问题区域,禁用相应的工具。例如,如果分析表明问题与特定存储引擎中的文件 I/O 无关,则禁用该引擎的文件 I/O 工具。然后截断历史和摘要表以删除以前收集的事件。

  4. 重复步骤 1 中的过程。

    在每次迭代中,Performance Schema 输出,尤其是 events_waits_history_long表格,包含越来越少的由无关紧要的仪器引起的噪音,并且鉴于该表格具有固定大小,包含越来越多与手头问题分析相关的数据。

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

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

    • 调整服务器参数(缓存大小、内存等)。

    • 通过不同的方式编写查询来调整查询,

    • 调整数据库架构(表、索引等)。

    • 调整代码(这仅适用于存储引擎或服务器开发人员)。

  6. 从第 1 步重新开始,查看更改对性能的影响。

和 列对于调查性能瓶颈或死锁极为重要mutex_instances.LOCKED_BY_THREAD_IDrwlock_instances.WRITE_LOCKED_BY_THREAD_ID这是通过 Performance Schema 检测实现的,如下所示:

  1. 假设线程 1 在等待互斥锁时卡住了。

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

    SELECT * FROM performance_schema.events_waits_current
    WHERE THREAD_ID = thread_1;

    假设查询结果标识线程正在等待在 中找到的互斥量 events_waits_current.OBJECT_INSTANCE_BEGINA。

  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;