MySQL profiling工具仅统计服务器内部各阶段耗时，不包含网络、锁等待等外部延迟；需先执行SELECT @@profiling确认为0后SET profiling=1开启，再查返回1方可生效；SHOW PROFILE FOR QUERY N中的N是当前会话语句顺序编号而非SQL ID；8.0.22+已弃用，推荐用performance_schema替代。
MySQL 的 profiling 工具不能精确测量“端到端”执行耗时，它只统计服务器内部各阶段的 CPU/引擎时间，不包含网络、锁等待、客户端解析等外部延迟——如果你看到 SHOW PROFILE 里加起来才 5ms，但应用层测出 200ms，这完全正常，不是工具不准，而是它本就不负责那部分。
怎么开 profiling 并确认它真在工作
先查当前会话是否支持并启用：SELECT @@profiling; 返回 0 就得手动开：SET profiling = 1;。注意这不是全局开关，只对当前连接有效；断开重连后要重设。再执行一次 SELECT @@profiling; 确认返回 1，才算真正就位。别跳过这步——很多情况下你以为开了，其实没生效。
SHOW PROFILE FOR QUERY N 中的 N 是什么
N 不是 SQL 的 ID 或 query_id，而是当前会话中被记录语句的**顺序编号**，从 1 开始递增，最多存 15 条（可调，但默认如此）。执行 SHOW PROFILES; 后第一列就是这个 N，第二列是总 Duration。如果中间执行了其他语句（比如 SELECT 1;），N 就会偏移，容易选错目标。建议分析前清空干扰：RESET QUERY CACHE;（若启用）或干脆新开一个干净会话。
哪些阶段耗时高才是真正的问题信号
别只盯 total 时间。真实瓶颈常藏在具体阶段里：
-
Creating tmp table或Copying to tmp table on disk→ 隐式临时表落地磁盘，说明GROUP BY/ORDER BY没走索引，或sort_buffer_size不够 -
Sorting result或Creating sort index→ 内存排序溢出，或缺失覆盖索引 -
Waiting for table metadata lock→ 其他会话正 ALTER 表或长事务未提交，但Duration不体现这段等待 -
Opening tables偏高 →table_open_cache设置太小，频繁打开物理文件
这些阶段名是 MySQL 内部真实行为标记，不是提示，是证据。
为什么你查不到数据，或者阶段对不上
MySQL 8.0.22+ 已将 profiling 标记为 deprecated，8.0.34 后彻底移除。即使你用的是 8.0.21，也可能因并发执行、预编译语句（PREPARE / EXECUTE）导致阶段丢失或错位。更关键的是：它不区分 CPU 时间和等待时间，所有锁等待都堆进 executing 阶段，看起来像“执行慢”，实则是卡在锁上。真要定位这种问题，必须切到 performance_schema 查 events_stages_history_long，或直接看慢日志里的 Lock_time 字段。
