慢查询卡在“解析与优化”阶段的典型表现是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) = '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。
