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比值来交叉验证。
