explain analyze必须实际执行查询，暴露引擎层与server层过滤行为；它能验证索引条件是否下推（icp），而普通explain仅显示预估计划。
EXPLAIN ANALYZE必须实际执行，别当普通EXPLAIN用
它不是只看计划，而是真跑一遍查询，把引擎层和Server层的过滤行为都暴露出来。如果你只关心“会不会走索引”，用EXPLAIN就够了；但想确认“索引到底有没有下推条件”“过滤是不是在引擎里做的”，就必须用EXPLAIN ANALYZE。
常见错误现象：在慢查询日志里看到某条SQL耗时高，直接加EXPLAIN发现type=ref、key=idx_status_time，就以为没问题——结果EXPLAIN ANALYZE一跑，rows_examined是rows_read的8倍，说明大量无效行被读上来才过滤。
- 必须在测试库或低峰期执行，避免影响线上
- 不支持
SELECT ... INTO OUTFILE、存储过程内嵌查询等部分语法 - 输出中
rows_read来自引擎（比如InnoDB），rows_examined是最终送到Server层的行数，二者差距大 = ICP没生效
对比FORCE INDEX前后，看ICP是否“隐身”
FORCE INDEX常让人误以为“指定索引就更准”，但它可能让原本能用的索引下推（ICP）直接失效。原因很简单：强制索引后，优化器不再评估该索引是否覆盖WHERE所有列，只要索引字段不全，就退回到Server层过滤。
使用场景：你怀疑当前优化器选的索引不是最优，想验证换一个索引会不会更好；或者想确认某个复合索引是否真能支撑当前WHERE条件。
- 先跑
EXPLAIN ANALYZE SELECT ... WHERE status = ? AND create_time > ?;，记下是否有index condition pushdown字样、Filtered行是否带(index condition) - 再跑
EXPLAIN ANALYZE SELECT ... FORCE INDEX (idx_status) WHERE status = ? AND create_time > ?;，对比rows_read是否明显上升、Filtered是否变成(table condition) - 如果加FORCE后
rows_examined / rows_read比值变大，说明原索引其实更合适，别硬换
WHERE写法稍有偏差，ICP就彻底不触发
哪怕索引建得完全正确，EXPLAIN ANALYZE里也看不到index condition pushdown。ICP对条件结构非常敏感，不是“有索引+有WHERE”就自动开。
典型失效写法：
-
WHERE status IN ('active', 'pending') AND create_time > '2024-01-01'——IN在多值时可能抑制ICP（尤其MySQL 8.0.18–8.0.28间有已知行为差异） -
WHERE status = ? AND DATE(create_time) = '2024-01-01'—— 函数包裹列，索引无法下推时间条件 -
WHERE status = ? OR create_time > ?——OR会让优化器放弃ICP，改用UNION或全表扫描 -
WHERE status = ? AND create_time > ? ORDER BY id LIMIT 10—— 如果idx_status_time不包含id，排序+分页可能打断ICP流程
看懂EXPLAIN ANALYZE输出里的关键三行
不用通读整棵树，盯住这三处就能快速判断索引利用质量：
-
rows_read：引擎从索引里读了多少行。越接近实际返回行数越好 -
Filtered: X.XX (index condition)：括号里必须是index condition，才是ICP真正生效；如果是table condition，说明过滤拖到了Server层 - 子节点中是否出现
index condition pushdown（树形格式下清晰）或Using index condition（传统格式Extra字段）——注意：EXPLAIN里有这个不等于EXPLAIN ANALYZE里真用了
最易被忽略的一点：rows_examined远大于rows_read时，别急着加索引或FORCE，先检查WHERE是否写了函数、隐式类型转换、或OR混用——这些比调优索引顺序更能立竿见影。
