MySQL Profiling功能用于定位单条SQL执行瓶颈，需SET profiling=1开启（8.0已移除），通过SHOW PROFILES和SHOW PROFILE FOR QUERY N查看各阶段耗时，辅助EXPLAIN与慢日志进行递进式性能分析。
如何开启和查看 MySQL 的 Profiling 功能
MySQL 的 PROFILE 功能是轻量级定位单条 SQL 执行瓶颈的内置工具，不需要安装插件或重启服务，但默认关闭。开启后它会记录语句在各执行阶段（如 parsing、executing、sending data）的耗时，比 EXPLAIN 更细，又比慢日志更即时。
实操建议：
- 先确认当前会话是否支持：
SELECT @@profiling;返回 0 表示未启用 - 开启当前会话 profiling：
SET profiling = 1; - 执行你想分析的 SQL（仅当前会话后续的语句会被记录）
- 用
SHOW PROFILES;查看最近执行的语句 ID 和总耗时 - 用
SHOW PROFILE FOR QUERY N;（N 是上一步查到的 Query_ID）看详细阶段耗时
注意：该功能只对当前连接有效，断开即清空；且不适用于存储过程内部语句（只记录 CALL 本身）。
常见耗时高却容易被忽略的阶段
很多人只扫一眼 total 时间，但真正卡点往往藏在中间阶段。比如 sending data 高，未必是网络问题，更可能是 MySQL 正在构建结果集（比如临时表排序、大字段拼接）；Copying to tmp table 高说明触发了隐式临时表（GROUP BY / DISTINCT / ORDER BY 涉及非索引列）。
典型误判场景：
-
Creating sort index耗时长 → 实际是ORDER BY没走索引，正在内存/磁盘排序 -
Waiting for query cache lock→ 表明启用了已废弃的 Query Cache（MySQL 8.0 已移除），反而拖慢并发 -
Opening tables高 → 可能是table_open_cache设置过小，频繁打开/关闭表文件
这些阶段名直接对应 MySQL 内部执行流程，不是“提示”，而是确凿的行为证据。
Profile 和 EXPLAIN、slow log 的关系怎么摆
EXPLAIN 告诉你“计划怎么走”，PROFILE 告诉你“实际每步花了多久”，slow log 告诉你“哪条语句整体超时”。三者不是替代关系，而是递进验证链。
使用建议：
- 先用
EXPLAIN看是否走了索引、有没有 Using filesort/Using temporary - 如果
EXPLAIN看不出问题但实际慢，再用PROFILE定位具体卡在哪一环 - 线上长期观察必须依赖
slow log+long_query_time配置，PROFILE只适合临时诊断
特别注意：PROFILE 不显示 I/O 细节（比如磁盘读次数），也不反映锁等待（如 Waiting for table metadata lock 属于锁状态，不在 profile 阶段里）。
MySQL 5.7 和 8.0 的兼容性差异
MySQL 8.0 默认禁用了 profiling 相关系统变量，SET profiling = 1 会报错 Unknown system variable 'profiling'。这不是 bug，是官方明确移除了该功能（文档注明 “deprecated in 5.7, removed in 8.0”）。
替代方案只有两个：
- 降级到 MySQL 5.7 或 Percona Server 等仍保留该功能的分支
- 改用 Performance Schema：
SELECT * FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE '%your_sql%';，但需要提前开启相关 consumers 和 instruments，配置成本高得多
所以如果你正在用 MySQL 8.0，别浪费时间找 SHOW PROFILE —— 它真没了，连命令都不存在。
