EXPLAIN显示的是优化器基于统计信息预估的执行路径，而非实际运行行为，因忽略锁等待、磁盘排序、并发争抢、缓存状态等运行时因素，常与真实执行偏差；需结合慢日志、performance_schema、SHOW PROFILE等运行时指标验证。
执行计划（EXPLAIN）为什么经常不准
MySQL 的 EXPLAIN 输出的是**优化器基于统计信息预估的执行路径**，不是真实运行时的行为。它不考虑锁等待、临时磁盘排序、并发资源争抢、查询缓存失效、缓冲池冷热状态等运行时因素，所以和实际执行常有偏差。
常见表现包括：
-
rows预估为 100，实际扫描了 50 万行（统计信息过期或直方图缺失） - 显示走
idx_a_b，但实际执行中因WHERE条件选择率突变，优化器在 runtime 切换为全表扫描 -
Extra: Using temporary; Using filesort在EXPLAIN中没出现，但慢日志里明确记录了磁盘排序
如何验证执行计划和实际行为是否一致
不能只看 EXPLAIN，必须结合运行时指标交叉验证：
- 用
EXPLAIN FORMAT=JSON查看query_block -> cost_info和used_columns，确认优化器是否“理解”你的索引覆盖意图 - 开启
performance_schema，查events_statements_history_long表，对比timer_wait和lock_time占比，判断瓶颈是否在 I/O 或锁 - 对关键 SQL 执行
SELECT * FROM table WHERE ... FOR UPDATE后立刻查INFORMATION_SCHEMA.INNODB_TRX，确认是否意外升级为行锁/间隙锁，引发阻塞 - 用
SHOW PROFILE FOR QUERY N（需先SET profiling = 1）看各阶段耗时，比如Creating sort index耗时远超预估，说明sort_buffer_size不足
哪些操作会让实际执行彻底偏离 EXPLAIN
以下情况会导致优化器“临场改判”，EXPLAIN 完全失效：
- 查询中含子查询且外层条件无法下推（如
WHERE id IN (SELECT ...)），MySQL 5.7+ 可能转为物化表，但EXPLAIN仍显示嵌套循环 - 使用
SQL_BUFFER_RESULT提示强制缓存中间结果，实际多了一次内存拷贝，EXPLAIN不体现 - 触发器或生成列（generated column）参与 WHERE 条件时，优化器可能放弃索引，但
EXPLAIN显示“Using index” - 分区表中跨分区查询，
EXPLAIN PARTITIONS显示扫描 3 个分区，但实际因锁粒度或 buffer pool 命中率低，IO 放大 5 倍
真正影响性能的关键点往往藏在执行后
EXPLAIN 只告诉你“想怎么跑”，而 slow_query_log 里的 Rows_examined、Rows_sent、tmp_tables、tmp_disk_tables 才告诉你“实际怎么跑”。尤其注意：Rows_examined 远大于 Rows_sent 时，大概率是索引未覆盖、回表过多或 JOIN 顺序错误；tmp_disk_tables > 0 说明 sort_buffer_size 或 join_buffer_size 设置过小——这些细节，EXPLAIN 一个字都不会提。
