定位SQL性能瓶颈的核心是看懂执行计划，重点检查访问路径是否合理、预估行数是否准确、是否存在高成本操作节点，并验证索引实际使用情况。
定位SQL性能瓶颈，核心是看懂执行计划（Execution Plan）。它不是神秘代码，而是数据库引擎告诉你“我打算怎么执行这条SQL”的详细路线图。重点不是记住所有算子名称，而是抓住几个关键指标：访问路径是否合理、数据量估算是否准确、是否存在隐式转换或临时表膨胀。
看懂执行计划的三个必查项
1. 访问类型（Access Type）是否走索引
关注 type 列（MySQL）或 Node Type + Index Name（PostgreSQL/Oracle）。
- const/ref/range 通常健康；ALL 表示全表扫描，需警惕。
- 即使显示 ref，也要核对 key 列是否用了预期索引，避免“索引失效”假象。
2. 预估行数（rows / Estimated Rows）是否严重偏差
数据库基于统计信息估算中间结果集大小。若实际返回10万行，而执行计划显示 rows=100，说明统计信息过期或谓词过于复杂导致估算失真。
- MySQL：运行 ANALYZE TABLE table_name 更新统计信息。
- PostgreSQL：执行 ANALYZE table_name。
- 偏差大时，执行计划可能选错连接顺序或算法（如该用Hash Join却选了Nested Loop）。
3. 是否出现高成本操作节点
重点关注以下节点（名称因数据库略有差异）：
- Using temporary / Using filesort（MySQL）→ 排序或分组未走索引，触发磁盘临时表。
- Hash Match 或 Sort 节点耗时占比 >30%（SQL Server/PostgreSQL）→ 内存压力大或缺少覆盖索引。
- Nested Loop 外层驱动表过大 → 检查连接条件是否有索引，或尝试改写为 JOIN … ON 显式关联。
常见陷阱：你以为在走索引，其实没有
这些情况会让索引“形同虚设”，但执行计划仍显示 type=ref 或类似字样：
- WHERE 子句对索引字段做函数操作：WHERE YEAR(create_time) = 2024 → 改为 WHERE create_time BETWEEN '2024-01-01' AND '2024-12-31'
- 隐式类型转换：WHERE user_id = '123'（user_id 是 INT）→ 字符串与整数比较会触发全表扫描
- 联合索引未满足最左前缀：INDEX (a,b,c)，查询条件只有 WHERE b = ? AND c = ? → 索引无法使用
- OR 条件拆分不当：WHERE a = 1 OR b = 2 → 若 a、b 无复合索引，可能放弃索引走全表
动手验证：从执行计划到优化落地
别只看“理论最优”，用数据验证每一步改进：
- 加 EXPLAIN FORMAT=JSON（MySQL 5.7+）或 EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）→ 获取真实执行耗时、IO次数、内存使用
- 对慢查询加 FORCE INDEX 或重写 JOIN 顺序，对比执行计划变化和实际耗时
- 用 SELECT ... INTO OUTFILE 或应用层缓存中间结果集，规避重复计算大表聚合
- 对高频小结果集查询，考虑物化视图（PostgreSQL）或冗余字段（如把 JSON 中的 status 提取为独立列并建索引）
执行计划不是终点，而是调优的起点。真正有效的优化，永远建立在理解数据分布、业务语义和引擎行为三者交集的基础上。
