首页 > 数据库 > Mysql > mysql使用performance_schema进行性能监控

mysql使用 performance_schema 进行性能监控

2026-03-03 09:54:59 作者：ruleslol

MySQL5.7及以上版本引入的performance_schema是一个高效的性能监控工具,替代了旧的SHOWPROFILES,它通过系统表实时收集SQL执行、锁等待、I/O等性能数据,提供了详细的监控功能,下面就来详细的介绍一下,感兴趣的可以了解一下

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

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

一、performance_schema是什么

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

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

mysql：存储用户、权限等元数据
information_schema：提供元数据视图（如表结构、列信息）
sys：基于 performance_schema 的简化视图（MySQL 5.7+）
performance_schema：提供底层性能监控数据

你可以用以下命令验证：

输出

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

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

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

USE performance_schema;
SHOW TABLES;

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

events_statements_current
events_statements_history
events_statements_summary_by_digest
events_waits_history
file_summary_by_instance
...

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

它们没有 .frm 或 .ibd 文件
你不能 INSERT、UPDATE、DELETE（只读）
查询它们时，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. 性能开销极低

performance_schema 使用环形缓冲区内存，不写磁盘
开销通常 < 5%，远低于 profiling=ON

4. 与慢查询日志互补

slow_query_log：记录超过阈值的 SQL（适合长期归档）
performance_schema：实时分析所有 SQL（适合开发调试）

四、总结：如何替代SHOW PROFILES

旧方式 (SHOW PROFILES)	新方式 (performance_schema)
SHOW PROFILES;	SELECT * FROM events_statements_history;
SHOW PROFILE FOR QUERY N;	SELECT * FROM events_stages_history WHERE NESTING_EVENT_ID=N;
手动开启 SET profiling=1;	默认开启，无需配置
仅当前会话有效	全局监控，支持多会话
已废弃（MySQL 8.0 移除）	官方推荐，功能更强大

五、推荐日常使用命令

-- 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 进行性能监控的文章就介绍到这了,更多相关mysql使用performance_schema进行性能监控内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！