如何通过MySQL Profiling工具监控SQL执行的每一步耗时？-mysql教程-PHP中文网

mysql 8.0.22+ 中 profiling 已弃用，8.0.34+ 默认不可用；确认支持需查 @@have_profiling（yes 表示编译支持）和 @@profiling（1 表示启用），替代方案是启用 performance schema 获取精确阶段耗时。

如何通过mysql profiling工具监控sql执行的每一步耗时？

MySQL 8.0.22+ 中 SET profiling = 1 已被标记为 deprecated，8.0.34 及以后版本默认不可用；若你正在用 MySQL 5.7 或早期 8.0（如 8.0.21），它仍可临时启用，但结果不稳定、不推荐用于生产诊断。

怎么确认当前 MySQL 是否支持 profiling

直接查变量，别猜版本号：

SELECT @@have_profiling; —— 返回 YES 表示编译时支持（但不代表能用）
SELECT @@profiling; —— 返回 0 就是关着的；返回 1 才真在记录
SHOW VARIABLES LIKE 'profiling'; —— 看值是否为 ON，注意：MySQL 8.0.22+ 这个变量可能仍存在但实际无效

如果连 @@have_profiling 都是 NO（某些精简版或云托管 RDS），说明压根没编译进去，SET profiling = 1 会报错 Unknown system variable 'profiling'。

开启后怎么查单条 SQL 的各阶段耗时

假设你确认支持且已开启：

先执行 SET profiling = 1;（仅对当前连接生效）
跑你要分析的语句，比如 SELECT * FROM orders WHERE status = 'shipped' ORDER BY created_at DESC LIMIT 50;
立刻执行 SHOW PROFILES; —— 注意看最末行的 Query_ID，不是时间戳最新那条，而是最后插入的序号
再执行 SHOW PROFILE FOR QUERY N;（N 是上一步看到的数字），就能看到 parsing、executing、sending data 等阶段的 Duration

常见误操作：SHOW PROFILE; 默认只显示最近一次查询，但如果中间执行过其他语句（比如 SELECT @@version），它可能就不是你想要的那条了。务必用 SHOW PROFILES; 核对 ID。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

为什么 Duration 加起来远小于客户端测出的总耗时

这是 profiling 最常被误解的地方：Duration 列只统计 MySQL 引擎内部纯计算/IO 时间，完全不包括：

网络往返延迟（TCP 建连、包传输、客户端解析结果）
锁等待时间 —— 比如卡在 Waiting for table metadata lock，但在 profiling 里对应阶段可能只显示 System lock 耗时几微秒，真实等待几百毫秒全被抹掉了
查询缓存锁（MySQL 5.7 中的 Waiting for query cache lock）、InnoDB 行锁争用、全局读锁等
操作系统调度抖动、上下文切换

所以当你看到 SHOW PROFILE FOR QUERY N 总和才 12ms，但应用层记录是 480ms，基本可以断定瓶颈在外部——立刻去查 information_schema.INNODB_TRX 和 performance_schema.data_lock_waits，别在 profiling 里死磕。

替代方案：Performance Schema 是唯一靠谱的路径

profiling 已废，真正能反映“指令级耗时”的只有 Performance Schema（PFS）。但默认它不开关键消费者：

先确认基础开关： SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema'; 必须是 ON
启用长历史表采集：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_history_long', 'events_stages_history_long');
打开仪器：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'statement/%' OR NAME LIKE 'stage/%';
执行目标 SQL 后，用 SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) AS sec FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE '%your_table%' ORDER BY EVENT_ID DESC LIMIT 1; 找到 EVENT_ID，再关联 events_stages_history_long 查各阶段真实皮秒级耗时

注意：TIMER_WAIT 单位是皮秒（10⁻¹² 秒），直接看数字毫无意义；除以 1000000000000 才是秒。漏这步，你会以为某阶段花了 3e12 秒——其实是 3 秒。