mysql执行SQL过程中执行计划和实际执行是否一致_mysql执行差异分析

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 一个字都不会提。