为什么需要看SQL执行计划
在日常开发或运维中，你可能遇到过这种情况：某个页面加载特别慢，点一下“查询”按钮卡好几秒。排查到最后，问题出在一条SQL语句上。这时候光看SQL本身是不够的，得知道它在数据库里到底怎么执行的——这就是执行计划的作用。
执行计划告诉你数据库是怎么查找数据的：用没用索引、扫描了多少行、是否做了临时表排序等等。掌握了这些信息，优化SQL就有了方向。
不同数据库查看执行计划的方法
MySQL：使用EXPLAIN命令
在MySQL中，只需要在你的SELECT语句前面加个EXPLAIN就行。
EXPLAIN SELECT * FROM users WHERE age > 25;执行后你会看到一张表，关键字段包括：
- type：连接类型，最好为ref或const，避免ALL（全表扫描）
- key：实际使用的索引
- rows：估算扫描的行数，越小越好
- Extra：额外信息，比如“Using where”、“Using filesort”都可能是性能隐患
如果发现type是ALL，rows动辄几千上万，那这条SQL大概率需要优化。
SQL Server：图形化与命令结合
在SQL Server Management Studio（SSMS）里，你可以直接点击“显示估计的执行计划”按钮（快捷键Ctrl+L），不用真正执行SQL就能看到执行路径。
也可以用命令：
SET SHOWPLAN_XML ON;
GO
SELECT * FROM Orders WHERE OrderDate > '2023-01-01';
GO
SET SHOWPLAN_XML OFF;
GO返回的是XML格式的执行计划，SSMS会自动渲染成图形，你能清楚看到哪个步骤耗时最高，比如是不是有个“Key Lookup”拖慢了速度。
PostgreSQL：EXPLAIN ANALYZE更精准
PostgreSQL的EXPLAIN命令也类似MySQL，但加上ANALYZE后会真正执行SQL并给出实际耗时。
EXPLAIN ANALYZE SELECT * FROM products WHERE price < 100;输出中会包含“Execution Time”，还能看到“Seq Scan”（顺序扫描）还是“Index Scan”（索引扫描）。如果明明有索引却走了全表扫描，可能是数据量小或者统计信息不准。
常见问题和优化提示
有时候你明明建了索引，执行计划却不用。常见原因有几个：
- 查询条件用了函数，比如WHERE YEAR(create_time) = 2023，会导致索引失效
- 字段类型不匹配，比如用字符串查数字字段
- 数据分布不均，优化器觉得走索引还不如全表扫
这时候可以尝试重写SQL，或者更新表的统计信息。
另外，联合索引要注意最左匹配原则。比如你建了(index_a, index_b)，但查询只用了index_b，那这个索引就用不上。
小技巧：模拟真实场景测试
别只在测试库里看执行计划。测试数据少，可能看不出问题。最好能在接近生产环境的数据量下验证。
比如你在本地导入一部分生产数据，再跑一遍EXPLAIN ANALYZE，可能会发现原本在小表上没问题的SQL，在大数据量下变成了性能黑洞。
看懂执行计划不是DBA的专利，每个写SQL的人都该掌握。下次遇到慢查询，别急着刷新页面，先看看执行计划怎么说。