EXPLAIN 不会报错，它只显示执行计划；真正出错的是后续 SELECT 执行阶段，仅当 EXPLAIN 自身语法错误、权限不足或格式不支持时才报错。
EXPLAIN 不会报错，它只显示执行计划
很多人在 MySQL 中执行 EXPLAIN SELECT ... 时看到“没反应”或“结果看不懂”，误以为是“执行错误”。实际上，EXPLAIN 本身不会报错——它只是把优化器预估的执行路径打印出来，哪怕原 SQL 语法错误、表不存在，EXPLAIN 也照常返回（但可能提示 NULL 或警告）。真正出错的是后续的 SELECT 执行阶段。
常见误解现象：
- 输入
EXPLAIN SELECT * FROM non_existent_table;→ 返回一行id=NULL, select_type=SIMPLE, table=NULL，没有报错 - 写错列名如
EXPLAIN SELECT unknow_col FROM t;→ 仍返回执行计划，但真正运行SELECT时才报Unknown column 'unknow_col' in 'field list' - 用
EXPLAIN FORMAT=JSON时拼错格式名（如FORMAT=JSOM）→ 这才会报错：Unknown EXPLAIN format: 'JSOM'
哪些情况会让 EXPLAIN 报错
只有 EXPLAIN 自身语法或权限问题才会触发错误。关键点在于：错误来自解析 EXPLAIN 命令本身，而非被分析的 SQL。
-
EXPLAIN后跟了不支持的语句类型：比如EXPLAIN INSERT ...在 MySQL 5.6 及更早版本中直接报错ERROR 1064 (42000): You have an error in your SQL syntax；MySQL 5.7+ 支持EXPLAIN INSERT/UPDATE/DELETE，但 8.0.19+ 才支持EXPLAIN ANALYZE - 格式参数错误：例如
EXPLAIN FORMAT=TREE SELECT ...在 MySQL 8.0.16 以下版本会报Unknown EXPLAIN format: 'TREE' - 权限不足：用户没有对目标表的
SELECT权限时，EXPLAIN SELECT会报ERROR 1142 (42000): SELECT command denied to user ... for table 't' - 使用了未启用的特性：如开启
optimizer_switch='use_index_extensions=off'后又在EXPLAIN中依赖该扩展，可能引发非预期的空计划或警告，但通常不报错
EXPLAIN 输出里哪些字段暗示潜在执行问题
真正需要警惕的不是“报错”，而是 EXPLAIN 结果中暴露的性能隐患。这些不会中断执行，却会导致慢查询、锁表甚至 OOM。
-
type字段为ALL：表示全表扫描，缺少有效索引；若rows值远大于实际匹配行数，说明索引未生效或统计信息过期 -
key为NULL：本应走索引却没走，常见于 WHERE 条件含函数（如WHERE YEAR(create_time) = 2023）、隐式类型转换（varchar字段与数字比较） -
Extra出现Using filesort或Using temporary：ORDER BY / GROUP BY 无法利用索引完成，需额外排序或临时表，数据量大时开销陡增 -
filtered值极低（如1.00表示 1%，10.00是 10%）：表示虽然走了索引，但索引过滤效率差，可能需要覆盖索引或调整条件顺序
验证索引是否真实生效的实操建议
别只信 EXPLAIN 的 key 和 rows，要结合实际执行确认。因为优化器基于统计信息做估算，而统计可能滞后或失真。
- 强制走某个索引测试：
EXPLAIN SELECT * FROM t USE INDEX (idx_status) WHERE status = 1;，对比rows和未指定时的差异 - 查看真实扫描行数：在 MySQL 5.7+ 中，打开
performance_schema，执行后查performance_schema.events_statements_history_long表的ROWS_EXAMINED字段 - 更新统计信息：
ANALYZE TABLE t;，尤其在大批量 INSERT/DELETE 后，避免优化器选错执行路径 - 注意
SQL_NO_CACHE（旧版本）或SELECT /*+ NO_ICP(t) */（8.0+）可禁用索引条件下推，用于排除 ICP 干扰判断
EXPLAIN FORMAT=JSON SELECT * FROM orders WHERE order_date > '2023-01-01' ORDER BY amount DESC\G
复杂查询务必用 FORMAT=JSON，它会明确写出是否用了 ICP、MRR、Range Checked for Each Record 等细节，比传统格式多出 3–5 倍诊断信息。
最常被忽略的一点：EXPLAIN 不会反映 MVCC 版本链遍历开销、锁等待时间、Buffer Pool 缓存命中率——这些只能靠 SHOW PROFILE、performance_schema.data_locks 或慢日志中的 Lock_time 和 Rows_sent/Rows_examined 比值来交叉验证。
