mysql-使用 performance_schema 进行性能监控

在 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 在各个执行阶段（如解析、优化、执行、发送结果等）的耗时。

步骤：

1. 先从 events_statements_history 中找到目标 EVENT_ID
2. 用该 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 性能调优的必备技能。