EXPLAIN最关键字段是type、key、rows、filtered和Extra：type决定扫描效率（ALL最差），key指示索引命中情况，rows为预估扫描行数，filtered反映过滤比例，Extra中Using filesort或Using temporary提示性能风险；FORMAT=JSON才能看清嵌套结构与成本细节。
EXPLAIN 能直接告诉你数据库实际怎么执行你的 SELECT，但不加 FORMAT=JSON 或看懂 type/key 字段，基本等于白看。
EXPLAIN 输出里哪些字段最关键
MySQL 8.0+ 默认输出是传统表格格式，真正影响性能的字段就几个：type、key、rows、filtered、Extra。其中 type 是扫描方式，从 system（最快）到 ALL（全表扫描，最危险）；key 显示是否命中索引，为空就说明没走索引；rows 是预估扫描行数，不是结果行数；Extra 里出现 Using filesort 或 Using temporary 就得警惕——排序或分组没走索引。
常见误读：rows 值小 ≠ 快，如果 type 是 ALL，哪怕 rows=100，也可能扫完整张表（因为统计信息不准）；key 显示某个索引名，不代表用上了全部列，得结合 key_len 看用了前几字节。
为什么加 FORMAT=JSON 才算真看清执行逻辑
默认文本格式会隐藏嵌套关系和代价估算，比如子查询、UNION、LATERAL 这类结构，在文本里压成一行，根本看不出执行顺序。而 EXPLAIN FORMAT=JSON 返回的是完整执行树，包含 cost_info、used_columns、attached_condition 等关键细节。
实操建议：
- 调试慢查询时，一律用
EXPLAIN FORMAT=JSON SELECT ...，别省这一步 - 重点关注 JSON 中的
query_block.nested_loop结构，它暴露了 JOIN 的实际驱动顺序 - 如果看到
"using_join_buffer": "Block Nested Loop"，说明没有合适索引，MySQL 在用缓存块做嵌套循环，大概率要优化 JOIN 条件或加索引
EXPLAIN 不会告诉你但必须手动验证的三件事
EXPLAIN 是预估，不执行，所以它不反映真实数据分布、锁竞争、缓冲池命中率这些运行时因素。你得自己补上验证：
- 执行
SELECT COUNT(*)对比EXPLAIN的rows，如果差 10 倍以上，说明统计信息过期，需运行ANALYZE TABLE - 在生产库低峰期对目标表加
SELECT ... FOR SHARE，观察是否被其他事务阻塞——EXPLAIN完全不体现锁行为 - 用
SHOW PROFILE或 performance_schema 查看真实耗时分布，确认瓶颈是在 “Sending data” 还是 “Copying to tmp table”，前者可能是磁盘 I/O，后者大概率是没走索引的 GROUP BY 或 ORDER BY
PostgreSQL 和 SQLite 的 EXPLAIN 差异点
语法看着像，但语义差别大：PostgreSQL 的 EXPLAIN (ANALYZE, BUFFERS) 是真执行并返回实际耗时和缓存读写次数，而 MySQL 的 EXPLAIN 永远不执行；SQLite 的 EXPLAIN QUERY PLAN 更轻量，只输出大致策略（如 “SCAN TABLE users” 或 “SEARCH TABLE orders USING INDEX idx_user_id”），不提供行数或索引长度。
所以跨数据库调优时：
- 在 PostgreSQL 上，优先用
EXPLAIN (ANALYZE, BUFFERS)，别只用基础EXPLAIN - SQLite 里想确认是否用索引，看输出里有没有
USING INDEX字样，没有就是全表扫描 - 别把 MySQL 的
key_len直接套到 PG 的输出里——PG 根本不提供这个字段
真正卡住人的往往不是看不懂 EXPLAIN 字段，而是忘了它不执行、不锁表、不反映并发压力——所有结论都得拿真实执行结果交叉验证。
