执行计划是否优化需综合判断：看EXPLAIN中type=ALL、key=NULL、rows过大，以及Extra含Using filesort/temporary；必须实测Query_time和Rows_examined，结合FORMAT=TREE分析cost偏差与过滤下推失败，并多次运行取中间值。
怎么看执行计划有没有优化
直接看
输出里有没有明显瓶颈项：如果
是
（全表扫描）、
是
（没走索引）、
数量远超实际匹配行数，基本说明没优化好。重点盯
字段——出现
或
就得警惕，尤其是二者同时出现时，大概率是排序+分组逻辑触发了磁盘临时表。
对比两条SQL的执行效率该比什么
不能只看
的估算值，必须实测真实开销：
用
避免查询缓存干扰（MySQL 5.7 及以前）；MySQL 8.0 要先确认
开启慢日志并设低阈值：
，再跑 SQL，查
表或日志文件里的
、
、
用
（需先
）看各阶段耗时，比如
或
占比过高，就对应到
里的问题
为什么
更适合对比
MySQL 8.0+ 的树形执行计划能直观暴露嵌套层级和代价估算偏差：
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
会显示每个子节点的
和
，方便定位“哪个 JOIN 或子查询突然放大了数据量”
对比时重点关注
（如果有启用
）和预估
的差值，差 5 倍以上说明统计信息过期，要
注意
这类运行时过滤条件，它意味着 WHERE 下推失败，可能因函数包裹字段（如
）导致索引失效
容易被忽略的对比陷阱
很多人只比单次执行时间，但缓存、连接状态、并发干扰会让结果失真：
第一次执行可能触发 buffer pool 加载，第二次才反映真实磁盘 I/O 压力；建议每条 SQL 至少跑 3 次，取中间值
用
（旧版）或
清空会话级状态，避免
计数污染
如果对比涉及
，注意
可能远大于
——优化器可能扫了 10 万行才凑够 10 条，这种“扫多送少”才是真实瓶颈
执行计划是否优化，最终得落在
和
的协同下降上，而不是某一行
字段看起来“变好了”。
EXPLAINtypeALLkeyNULLrowsExtraUsing filesortUsing temporaryEXPLAINSELECT SQL_NO_CACHE ...query_cache_type=OFFSET long_query_time = 0.01;slow_logQuery_timeRows_examinedRows_sentSHOW PROFILE FOR QUERY N;SET profiling = 1;Sorting resultCreating tmp tableEXTRAEXPLAIN FORMAT=TREEFORMAT=TREEcostrowsactual costoptimizer_tracecostANALYZE TABLE-> Filter: ...WHERE YEAR(create_time)=2023RESET QUERY CACHE;FLUSH STATUS;Handler_read_*LIMITrows_examinedrows_sentRows_examinedQuery_timeEXPLAIN