SHOW PROFILE仅适用于MySQL 5.7及更早版本，执行前须确认版本（SELECT VERSION()）和profiling开关状态（SELECT @@profiling），开启后执行SQL并立即用SHOW PROFILE FOR QUERY N分析各阶段耗时，MySQL 8.0+应改用Performance Schema。
确认 MySQL 版本和 profiling 开关状态
别跳过这步——SHOW PROFILE 在 MySQL 5.7 中可用，但默认关闭，且只对当前会话生效。执行前先验证：
查版本：SELECT VERSION(); —— 必须是 5.7.x，不是 8.0+；
查开关：SELECT @@profiling; —— 返回 0 表示未开启；
开开关：SET profiling = 1; —— 注意：新连接、重启后失效，不能设为全局；
顺手看下历史容量：SELECT @@profiling_history_size; —— 默认 15，超了旧记录会被覆盖，高并发调试时建议设大点（如 SET profiling_history_size = 100;）。
执行目标 SQL 后立刻查 profile，别等
SHOW PROFILE 查的是“上一条语句”或指定 QUERY_ID，中间插一条其他 SQL 就会覆盖原记录。真实操作必须连贯：
- 先跑一次
EXPLAIN SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC;，确认索引使用情况； - 紧接着执行同一条语句（不加
EXPLAIN）； - 马上执行
SHOW PROFILES;找到对应Query_ID； - 立刻执行
SHOW PROFILE FOR QUERY N;（N 是刚看到的 ID）； - 避免在分析期间执行
SELECT @@...或管理命令，它们也会计入 profile 序列。
输出里重点关注 Status 列（如 Sending data、Creating sort index）和 Duration（单位秒，精度微秒）。
识别关键耗时阶段及对应优化方向
总时间长 ≠ 瓶颈明确，不同 Status 暴露的问题类型差异很大：
-
Creating tmp table：大概率是GROUP BY、ORDER BY非索引字段，或UNION—— 检查是否能加联合索引，或改写查询避免排序/分组； -
Copying to tmp table：结果集太大，内存临时表撑不住转磁盘了 —— 看tmp_table_size和max_heap_table_size，但优先缩小WHERE范围或加覆盖索引； -
Sorting result：排序没走索引 —— 确认ORDER BY字段是否有合适索引，注意联合索引字段顺序必须匹配； -
Waiting for query cache lock：说明启用了 query cache（5.7 默认开），并发高时锁争用严重 —— 直接关掉更稳妥：SET GLOBAL query_cache_size = 0;； -
freeing items或cleaning up占比异常高：可能涉及大量临时对象释放，常与大事务、长连接或未关闭游标有关。
用 CPU / BLOCK IO 等类型细化分析
SHOW PROFILE 支持按资源维度展开，最常用的是 CPU 和 BLOCK IO：
查 CPU 分布：SHOW PROFILE CPU FOR QUERY 3; —— 看 User_time 和 System_time，若 System_time 显著偏高，可能是内核调度或锁竞争问题；
查磁盘 IO 次数：SHOW PROFILE BLOCK IO FOR QUERY 3; —— 关注 InnoDB 相关的 read_requests、write_requests，结合 Handler_read_* 状态变量交叉验证；
查所有维度：SHOW PROFILE ALL FOR QUERY 3; —— 适合初次排查，但信息量大，建议先聚焦 CPU 或 ALL；
注意：MEMORY 类型在多数 5.7 版本中无效，SOURCE 需要 debug 版本支持，生产环境基本不用。
真正容易被忽略的是：profile 数据只存于当前会话内存中，断开就丢；且 SHOW PROFILE 不告诉你是否用了索引，它只反映执行过程中的实际行为。你得把 EXPLAIN 的预估计划和 SHOW PROFILE 的实测耗时配对看，才能判断“为什么索引没被高效利用”。
