mysql执行慢查询是卡在哪个阶段_执行流程定位方法

慢查询卡在“解析与优化”阶段的典型表现是SELECT语句简单但执行时间波动大、EXPLAIN显示全表扫描或预估行数远超实际，且SHOW PROFILE中optimizing阶段耗时异常高，主因是查询重写或统计信息计算开销大。

慢查询卡在“解析与优化”阶段的典型表现

当 SELECT 语句本身不复杂，但执行时间波动大、EXPLAIN 显示 type=ALL 或 rows 远超实际结果集，且 SHOW PROFILE 中 starting → checking permissions → Opening tables → init → optimizing 阶段耗时异常高，大概率是卡在查询重写或统计信息计算上。MySQL 8.0+ 默认启用 optimizer_switch='condition_fanout_filter=on'，遇到多表 JOIN + 复杂 WHERE 时可能触发代价误估，反复回表估算行数。

• 确认是否开启直方图：SELECT * FROM information_schema.COLUMN_STATISTICS WHERE TABLE_NAME = 'your_table';
• 临时关闭代价敏感优化：SET optimizer_switch='condition_fanout_filter=off';，再跑一次对比
• 避免在 WHERE 中对索引字段用函数：WHERE DATE(create_time) = '2025-01-01' 会跳过索引，改用 WHERE create_time >= '2025-01-01' AND create_time

如何用 SHOW PROFILE 定位真实瓶颈点

SHOW PROFILE 能暴露每个内部阶段的耗时，比单纯看 Query_time 精确得多。它不是默认开启的，需手动启用并限制采集范围，否则影响性能。

• 开启前先检查是否支持：SELECT @@have_profiling;（5.7+ 已废弃，但依然可用；8.0+ 需用 performance_schema 替代）
• 启用采集：SET profiling = 1;，然后执行慢 SQL
• 查看各阶段耗时：SHOW PROFILES; 找到 Query_ID，再执行 SHOW PROFILE FOR QUERY N;
• 重点关注：statistics（读取统计信息）、creating sort index（文件排序）、Copying to tmp table（隐式临时表）、Waiting for table flush（DDL 冲突）

mysql> SHOW PROFILE FOR QUERY 1;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000068 |
| checking permissions | 0.000012 |
| Opening tables       | 0.000031 |
| init                 | 0.000022 |
| optimizing           | 0.000145 |
| statistics           | 0.021890 | <-- 这里异常高，说明统计信息陈旧或扫描成本误判
| preparing            | 0.000027 |
| executing            | 0.000005 |
| Sending data         | 0.000312 |
+----------------------+----------+

真正卡在存储引擎层的信号：Handler_read_* 指标飙升

如果 SHOW PROFILE 中 Sending data 占比极高（>80%），且 EXPLAIN 的 key 字段为 NULL，说明 MySQL 已把执行计划交给了 InnoDB，瓶颈在底层数据读取。此时要看 Handler_read_* 状态变量：

• Handler_read_first 高 → 全索引扫描（没走好索引）
• Handler_read_key 低但 Handler_read_next 极高 → 索引范围扫描但返回大量行，或索引选择性差
• Handler_read_rnd 高 → 排序/分组用了临时表且未命中索引，

  

  触发随机 I/O
• 查实时值：SHOW GLOBAL STATUS LIKE 'Handler_read%';，执行前后对比差值

8.0+ 必须转向 performance_schema 的原因

MySQL 5.7 的 profiling 在 8.0 中被标记为 deprecated，且无法跟踪子查询、CTE、存储过程内部。真实生产环境必须用 performance_schema 的事件采集能力。

• 启用相关消费者：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events%';
• 开启语句级等待事件：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME = 'statement/sql/select';
• 查慢语句详情：SELECT * FROM performance_schema.events_statements_history_long WHERE SQL_TEXT LIKE '%your_table%' ORDER BY TIMER_WAIT DESC LIMIT 1;
• 关键字段：TIMER_WAIT（总耗时）、LOCK_TIME（锁等待）、ROWS_SENT/ROWS_EXAMINED（结果/扫描行数）

真正难定位的慢查询，往往不是语法问题，而是优化器在“估算”和“真实数据分布”之间失配——比如直方图缺失、索引统计过期、或者 JSON 列上用了 JSON_CONTAINS 却没建函数索引。这些不会报错，但会让 optimizing 阶段卡住几十毫秒，而你只看到 Query_time: 1.23s。