EXPLAIN关键字段为type、key、rows、Extra：type为ALL是全表扫描，ref/range才合理用索引；key为空表示未走索引；rows远大于实际行数说明索引失效或统计不准；Extra含Using filesort/temporary需警惕；key_len偏小表明联合索引未完全命中；filtered过低提示选择性差。
EXPLAIN 输出字段怎么看
直接看 EXPLAIN 结果里最常出问题的几列： type、key、rows、Extra。它们决定查询快不快、走不走索引、有没有回表。
比如 type 是 ALL，基本等于全表扫描；type 是 ref 或 range 才算合理用了索引；key 为空说明压根没走索引；rows 数值远大于实际返回行数，大概率是索引失效或统计信息不准。
-
Extra出现Using filesort或Using temporary，排序或分组没走索引，要警惕 -
key_len值比预期小（比如联合索引有三列，但只用了前两列），说明索引没完全命中 -
filtered值过低（比如
为什么加了索引，EXPLAIN 还显示 type=ALL
常见原因是条件字段隐式类型转换或函数包裹，导致索引失效。
- 字符串字段用数字比较：
WHERE user_id = 123（user_id是VARCHAR）→ 触发隐式转换，索引失效 - 对字段用函数：
WHERE DATE(create_time) = '2024-01-01'→ 索引无法下推 - LIKE 以通配符开头：
WHERE name LIKE '%abc'→ 无法使用 B+ 树索引的前缀特性 - 联合索引顺序错：
INDEX (a,b,c)，但查询只用了b = ? AND c = ?，跳过首列a，索引失效
EXPLAIN FORMAT=TREE 和 FORMAT=TRADITIONAL 的区别
FORMAT=TREE 是 MySQL 8.0+ 引入的，用树形结构展示执行流程和代价估算，比传统格式更贴近真实执行逻辑；FORMAT=TRADITIONAL（默认）是表格形式，兼容老版本但信息较扁平。
-
FORMAT=TREE会显示cost、rows、是否使用缓存、是否物化子查询等细节，适合调优复杂 JOIN 或子查询 -
FORMAT=TRADITIONAL更适合快速扫一眼驱动表、访问类型、是否用索引 - 注意：
FORMAT=TREE不支持某些旧语法（比如部分存储过程内嵌查询），报错时可切回默认格式
EXPLAIN ANALYZE 要不要在生产环境跑
不要。它真执行 SQL 并记录实际耗时、行数、缓冲区使用等，可能锁表、拖慢服务、污染查询缓存。
-
EXPLAIN ANALYZE适合开发/测试库验证执行计划是否和预估一致（比如rows预估 100，实际扫描 100000） - 生产排查慢查，优先用
EXPLAIN+slow_log+performance_schema定位，避免直接执行 - 如果必须验证，先
SET profiling = 1或用SELECT ... INTO DUMMY_TABLE降低影响，但仍有风险
真正难的不是看懂 EXPLAIN 字段，而是把 key、type、Extra 和你写的 WHERE 条件、索引定义、表数据分布串起来——同一句 SQL，在 10 行表和 1000 万行表上，MySQL 可能选完全不同执行路径。
