最直接的方法是用EXPLAIN命令查看SQL执行计划，它显示索引使用、扫描方式、临时表及排序等关键信息；MySQL支持EXPLAIN SELECT，PostgreSQL支持EXPLAIN和EXPLAIN ANALYZE，需重点关注type、key、rows和Extra字段。
想看SQL执行计划，最直接的方法就是用EXPLAIN命令——它能告诉你数据库怎么执行这条SQL，用了哪些索引、是否走全表扫描、有没有临时表或文件排序。掌握它，是定位慢查询的第一步。
基础用法：EXPLAIN + SQL语句
在要分析的SQL前加上EXPLAIN即可（MySQL / PostgreSQL / SQLite均支持，语法略有差异）：
- MySQL：直接写
EXPLAIN SELECT * FROM users WHERE id = 1; - PostgreSQL：支持
EXPLAIN、EXPLAIN ANALYZE（后者会真实执行并返回实际耗时和行数） - 注意：不要对INSERT/UPDATE/DELETE直接加EXPLAIN（MySQL 8.0+支持
EXPLAIN UPDATE，但多数场景建议改写为等价SELECT再分析）
关键字段解读：看懂输出的核心列
以MySQL为例，重点关注这几列：
-
type：连接类型，从好到差常见为
const≈eq_ref>ref>range>index>ALL（全表扫描，需警惕） -
key：实际使用的索引名；为
NULL说明没走索引 -
rows：预估扫描行数；数字越大越可能慢，结合
filtered看实际命中率 -
Extra：重要提示区；出现
Using filesort（需要额外排序）、Using temporary（建临时表）、Using join buffer（非驱动表走BNL）都意味着性能风险
进阶技巧：让分析更准更实用
单看EXPLAIN有时不够，配合这些操作才能抓住真问题：
- 加
FORMAT=JSON（MySQL 5.6+）：EXPLAIN FORMAT=JSON SELECT ...，能看到更细的代价估算、访问路径决策依据 - 对比
EXPLAIN和EXPLAIN ANALYZE（PostgreSQL）：前者是预估，后者是实测，能发现统计信息不准导致的误判 - 检查
SHOW INDEX FROM table_name：确认索引是否存在、字段顺序是否匹配查询条件和ORDER BY - 对复杂查询分段EXPLAIN：把子查询、JOIN拆成独立SELECT，逐个分析，避免被整体执行计划掩盖局部瓶颈
常见误区提醒
别被表面现象带偏：
- 看到
key有值≠高效：如果rows极大，或Extra里有Using where（表示索引下推失败，回表过滤），仍可能慢 -
type=ref不等于走了最优索引：要结合key_len看用了索引的几列，是否覆盖了所有WHERE条件 - 执行计划会随数据量、统计信息、MySQL版本变化：测试环境结果不能直接套用到生产，上线前务必在相似数据规模下验证
基本上就这些。EXPLAIN不是万能钥匙，但它是最可靠的起点——多看几次，对照SQL逻辑反推，慢慢就能一眼识别出“哪里卡住了”。
