Performance Schema是定位MySQL性能瓶颈的核心工具，通过分析等待事件、SQL语句摘要和资源竞争，可精准识别I/O、锁、高频率查询等深层次问题，实现从宏观到微观的性能优化。
利用MySQL性能模式（Performance Schema）来监控数据库瓶颈，在我看来，是深入了解MySQL内部运行机制、精准定位性能问题的最有效途径之一。它提供了一种前所未有的细粒度视角，让我们能够看到服务器内部到底在忙些什么、等待些什么，远超传统的慢查询日志或
SHOW STATUS
所能提供的洞察力。
解决方案
要真正摸清MySQL的脾气，Performance Schema是个不可多得的内窥镜。它的核心在于收集各种事件数据，包括等待事件（waits）、语句事件（statements）、阶段事件（stages）等，并将这些数据存储在
performance_schema
数据库的表中。
启用Performance Schema通常很简单，在
my.cnf
配置文件中加入或确保
performance_schema = ON
，然后重启MySQL服务即可。不过，我个人觉得，很多人一开始会觉得Performance Schema的表太多太复杂，但一旦你掌握了几个核心视图，它简直就是个宝藏。
我们的工作流程通常是这样的：
全局概览，定位主要等待类型： 从
events_waits_summary_global_by_event_name
或
events_waits_summary_by_thread_by_event_name
这些聚合表中，我们可以快速发现系统大部分时间都在等待什么。是I/O？是锁？还是内部的同步机制？深挖高开销SQL语句： 接下来，我会转向
events_statements_summary_by_digest
。这个表非常强大，它能将相似的SQL语句归类（通过
DIGEST
字段），并统计它们的总执行时间、锁时间、扫描行数等。这能帮我揪出那些表面上看起来不慢，但因为执行频率极高，累积起来却耗费大量资源的“隐形杀手”。分析语句执行阶段： 如果某个SQL语句被标记为高开销，我会进一步查看
events_stages_summary_by_thread_by_event_name
或
events_stages_history_long
，看看这条语句在执行过程中，具体是哪个阶段消耗了大量时间，比如“Sending data”、“Sorting result”或者“optimizing”。追踪资源竞争： 对于I/O或锁等待，我会结合
file_summary_by_event_name
、
table_io_waits_summary_by_table
、
mutex_summary_by_instance
等表，更细致地分析是哪个文件、哪个表、哪个内部互斥量成了瓶颈。
通过这样的层层递进，我们就能从宏观到微观，逐步锁定数据库的性能瓶颈。
如何有效解读Performance Schema的等待事件数据？
刚开始看Performance Schema的等待事件名称，简直像天书，比如
wait/io/file/innodb/innodb_data_file
或者
wait/synch/mutex/innodb/buf_pool_mutex
，但仔细琢磨，它们其实在告诉你系统到底在等什么。要有效解读这些数据，我们通常会关注
performance_schema.events_waits_summary_global_by_event_name
这张表。
这张表聚合了所有等待事件，我们可以通过
SUM_TIMER_WAIT
（总等待时间）和
COUNT_STAR
（事件发生次数）来排序，找出那些最耗时或发生频率最高的等待事件。
举个例子，如果我看到
wait/io/file/sql/binlog
的
SUM_TIMER_WAIT
非常高，那我就知道MySQL大部分时间都在等待二进制日志的写入，这可能意味着我的磁盘I/O存在瓶颈，或者binlog的配置（比如
sync_binlog
参数）过于激进。
SELECT EVENT_NAME, SUM_TIMER_WAIT / 1000000000000 AS total_wait_s, -- 转换为秒 COUNT_STAR AS event_count, AVG_TIMER_WAIT / 1000000000 AS avg_wait_ms -- 转换为毫秒FROM performance_schema.events_waits_summary_global_by_event_nameORDER BY SUM_TIMER_WAIT DESCLIMIT 10;
如果
wait/lock/table/sql/handler
这类事件高居榜首，那么显而易见，数据库中存在大量的表级锁竞争，这通常指向了某些长时间运行的事务、不合理的索引设计导致的全表扫描，或者并发更新同一张表的场景。我上次遇到一个奇怪的间歇性慢查询，最后发现是某个不常用的表上，因为缺乏索引导致全表扫描，进而引发了不必要的锁等待，Performance Schema一下子就暴露了这个问题。解读这些事件，关键在于将它们与实际的业务操作和数据库配置联系起来。
针对高开销SQL语句，Performance Schema提供了哪些深度分析能力？
我发现很多时候，大家只关注执行时间长的语句，但Performance Schema能帮你看到那些执行很快但频率极高，累积起来却耗费大量资源的“隐形杀手”。
performance_schema.events_statements_summary_by_digest
就是为此而生的。
这张表通过
DIGEST
字段对SQL语句进行标准化处理，比如
SELECT * FROM users WHERE id = 1
和
SELECT * FROM users WHERE id = 2
会被视为同一个
DIGEST
。这样，我们就能统计到同一类SQL语句的总开销。
神采PromeAI
将涂鸦和照片转化为插画，将线稿转化为完整的上色稿。
103 查看详情 
我们可以关注以下几个关键指标：
SUM_TIMER_WAIT
: 这类语句的总执行时间。
COUNT_STAR
: 这类语句的总执行次数。
SUM_LOCK_TIME
: 这类语句在等待锁上的总时间。
SUM_ROWS_EXAMINED
: 这类语句总共扫描了多少行数据。
SUM_ROWS_SENT
: 这类语句总共返回了多少行数据。
SELECT DIGEST_TEXT, SUM_TIMER_WAIT / 1000000000000 AS total_exec_s, COUNT_STAR AS exec_count, SUM_LOCK_TIME / 1000000000000 AS total_lock_s, SUM_ROWS_EXAMINED AS total_rows_examinedFROM performance_schema.events_statements_summary_by_digestORDER BY SUM_TIMER_WAIT DESCLIMIT 10;
通过查询，如果我发现某个
UPDATE
语句，单次执行可能很快，但因为
COUNT_STAR
极高，导致
SUM_TIMER_WAIT
和
SUM_LOCK_TIME
累积起来非常可观，那么我就知道虽然它不是“慢查询”，但它却是“高开销查询”，需要优化其执行频率或并发策略。
更进一步，如果我想看某个具体
DIGEST
的详细执行历史，我可以利用
performance_schema.events_statements_history_long
，它记录了最近N条语句的完整信息，包括线程ID、错误码等，这对于复现问题和定位具体是哪个应用实例发出的高开销语句非常有帮助。这种深度的分析能力，远比简单的慢查询日志只能记录超过某个阈值的语句要全面得多。
如何利用Performance Schema追踪文件I/O和内存锁竞争？
当数据库性能出现瓶颈时，文件I/O和内存锁竞争往往是幕后黑手。Performance Schema提供了专门的视图来揭示这些低层次的细节。
文件I/O追踪：
performance_schema.file_summary_by_event_name
和
performance_schema.file_summary_by_instance
是分析文件I/O的关键。
file_summary_by_event_name
按文件事件类型（如数据文件读写、日志文件读写）聚合，而
file_summary_by_instance
则更具体，它会列出每个实际文件的I/O统计。
-- 按事件类型查看文件I/OSELECT EVENT_NAME, SUM_TIMER_WAIT / 1000000000000 AS total_io_s, COUNT_STAR AS io_count, SUM_NUMBER_OF_BYTES_READ AS bytes_read, SUM_NUMBER_OF_BYTES_WRITE AS bytes_writtenFROM performance_schema.file_summary_by_event_nameORDER BY SUM_TIMER_WAIT DESCLIMIT 10;-- 按文件实例查看文件I/OSELECT FILE_NAME, EVENT_NAME, SUM_TIMER_WAIT / 1000000000000 AS total_io_s, COUNT_STAR AS io_countFROM performance_schema.file_summary_by_instanceORDER BY SUM_TIMER_WAIT DESCLIMIT 10;
我记得有一次，我们的数据库I/O突然飙升，但业务流量并没有明显变化。通过
file_summary_by_instance
，我发现是某个特定的临时文件操作（
#sql_XXXX.MYD
）导致了大量的磁盘写入。最终定位到是一个复杂报表查询在后台默默地生成了巨大的临时表。这种深层次的洞察，是慢查询日志很难给到的，它直接指向了物理资源层面的瓶颈。
内存锁竞争追踪：
对于内存锁（互斥量，mutex）和读写锁（rwlock）的竞争，我们可以查看
performance_schema.mutex_summary_by_instance
和
performance_schema.rwlock_summary_by_instance
。这些表会显示MySQL内部各种锁的等待情况。
-- 查看互斥量竞争SELECT OBJECT_INSTANCE_BEGIN, EVENT_NAME, SUM_TIMER_WAIT / 1000000000000 AS total_wait_s, COUNT_STAR AS wait_countFROM performance_schema.mutex_summary_by_instanceORDER BY SUM_TIMER_WAIT DESCLIMIT 10;
高开销的内存锁竞争通常意味着MySQL内部的并发瓶颈。例如，如果
buf_pool_mutex
（InnoDB缓冲池互斥量）的等待时间非常高，那可能意味着缓冲池的并发访问存在问题，或者缓冲池本身配置不合理。虽然这类问题通常需要更深入的MySQL内核知识来解决，但Performance Schema至少能明确地指出问题发生在哪个内部组件上，为我们后续的优化指明方向。它提供了一种透明度，让我们能看到MySQL服务器在处理请求时，到底在哪些地方卡住了。
以上就是利用MySQL性能模式（Performance Schema）监控数据库瓶颈的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/942750.html
微信扫一扫 
支付宝扫一扫 
