慢查询卡在“解析与优化”阶段的典型表现
当
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) = '2024-01-01'会跳过索引，改用
WHERE create_time >= '2024-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。
