mysql使用performance_schema进行性能监控

在 MySQL 5.7 及以上版本中，performance_schema（简称 P_S） 是官方推荐的、用于替代 SHOW PROFILES 的低开销性能监控机制。

它默认开启（无需手动启用），通过一系列系统表实时收集 SQL 执行、锁等待、I/O、内存等详细性能数据。

一、performance_schema是什么

performance_schema 是一个「数据库」（Database / Schema）

在 MySQL 中，performance_schema 是 内置的系统数据库之一，和以下这些是同一类：

你可以用以下命令验证：

输出

编辑
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |  ← 看！它是一个数据库！
| sys                |
| your_app_db        |
+--------------------+

它里面有很多「表」，但这些表是「内存中的虚拟表」

进入 performance_schema 数据库后，你可以看到很多表：

USE performance_schema; SHOW TABLES;

你会看到上百张表，例如：

⚠️ 注意：这些表 不是磁盘上的真实文件，而是 MySQL 内存中动态生成的“视图”或“接口”，用于暴露内部性能数据。

所以，performance_schema 是一个特殊的只读系统数据库，它的“表”其实是性能监控的 API 接口。

二、高效性能分析

下面以 “监控最近执行的慢查询及其耗时” 为例，手把手教你如何使用 performance_schema 进行高效性能分析。

第一步：确认performance_schema已启用

SHOW VARIABLES LIKE 'performance_schema'; 如果返回 ON → 正常可用（MySQL 5.7+ 默认开启）如果是 OFF → 需在 my.cnf 中添加 performance_schema=ON 并重启 MySQL

第二步：查看最近执行的 SQL 语句（类似SHOW PROFILES）

关键表：events_statements_history

它记录了每个连接最近执行的若干条 SQL（数量由 performance_schema_events_statements_history_size 控制，默认 10 条/连接）。

查看所有最近执行的语句（含耗时）：

SELECT THREAD_ID, EVENT_ID, SQL_TEXT, TIMER_WAIT / 1000000000000 AS exec_time_sec -- 转换为秒 FROM performance_schema.events_statements_history WHERE SQL_TEXT IS NOT NULL ORDER BY EVENT_ID DESC LIMIT 10;

输出示例：

THREAD_ID | EVENT_ID | SQL_TEXT                     | exec_time_sec
45        | 12345    | SELECT * FROM users WHERE id=1 | 0.0023

TIMER_WAIT 单位是皮秒（picoseconds），除以 10^12 得到秒。

第三步：查看某条 SQL 的详细阶段耗时（类似SHOW PROFILE）

关键表：events_stages_history

记录每条 SQL 在各个执行阶段（如解析、优化、执行、发送结果等）的耗时。

步骤：

先从 events_statements_history 中找到目标 EVENT_ID用该 EVENT_ID 查询对应的阶段信息：

-- 假设上一步查到 EVENT_ID = 12345 SELECT EVENT_NAME AS stage, TIMER_WAIT / 1000000000000 AS duration_sec FROM performance_schema.events_stages_history WHERE NESTING_EVENT_ID = 12345 ORDER BY TIMER_START;

输出示例：

stage                              | duration_sec
stage/sql/Opening tables           | 0.0001
stage/sql/System lock              | 0.00002
stage/sql/optimizing               | 0.0003
stage/sql/executing                | 0.0015

这就相当于 SHOW PROFILE FOR QUERY ... 的效果，但更结构化！

第四步：监控“慢查询”（自动捕获耗时长的 SQL）

方法：使用events_statements_summary_by_digest

这个表会自动聚合相同模式的 SQL（如 SELECT * FROM t WHERE id=?），并统计平均耗时、最大耗时、执行次数等。

SELECT DIGEST_TEXT AS normalized_sql, -- 参数化后的SQL模板 COUNT_STAR AS exec_count, AVG_TIMER_WAIT / 1000000000000 AS avg_time_sec, MAX_TIMER_WAIT / 1000000000000 AS max_time_sec, SUM_ROWS_EXAMINED / COUNT_STAR AS avg_rows_examined FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT IS NOT NULL ORDER BY avg_time_sec DESC LIMIT 10;

这是 最实用的性能分析入口！可以快速发现：

哪些 SQL 平均耗时最长？哪些 SQL 扫描行数最多？哪些 SQL 执行频率最高？

第五步：实时监控当前正在执行的 SQL

使用events_statements_current

SELECT PROCESSLIST_ID AS conn_id, SQL_TEXT, TIMER_WAIT / 1000000000000 AS running_time_sec FROM performance_schema.events_statements_current WHERE SQL_TEXT IS NOT NULL;

结合 SHOW PROCESSLIST，可定位卡住的查询。

三、实用技巧 & 注意事项

1. 清空历史统计（重置计数器）

TRUNCATE TABLE performance_schema.events_statements_summary_by_digest;

2. 开启更多监控项（默认已开启大部分）

检查是否启用 statement 监控：

SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE '%statement%'; -- 确保 events_statements_current/history/summary 都是 ENABLED

3. 性能开销极低

4. 与慢查询日志互补

四、总结：如何替代SHOW PROFILES

五、推荐日常使用命令

-- 1. 查看最近10条SQL及耗时 SELECT SQL_TEXT, TIMER_WAIT/1e12 AS sec FROM performance_schema.events_statements_history ORDER BY EVENT_ID DESC LIMIT 10; -- 2. 查找最慢的SQL模板 SELECT DIGEST_TEXT, AVG_TIMER_WAIT/1e12 AS avg_sec FROM performance_schema.events_statements_summary_by_digest ORDER BY avg_sec DESC LIMIT 5;

通过 performance_schema，你不仅能获得比 SHOW PROFILES 更丰富的信息，还能实现自动化监控、告警和根因分析，是现代 MySQL 性能调优的必备技能。

到此这篇关于mysql使用 performance_schema 进行性能监控的文章就介绍到这了,