在日常开发中，写完一条SQL语句只是第一步，真正影响系统性能的往往是它的执行效率。比如你在一个订单系统里查“某用户近三个月的消费记录”，如果页面卡了三秒才出结果，问题很可能出在SQL执行路径上。这时候，查看SQL查询执行计划就成了排查性能瓶颈的关键手段。
什么是SQL查询执行计划
执行计划是数据库引擎在运行SQL语句前，生成的一套“路线图”。它告诉你数据库会以什么顺序访问表、是否使用索引、是否进行全表扫描、是否做表连接等。通过这个计划，你能看出SQL到底“做了什么”和“为什么慢”。
主流数据库中的查看方式
不同数据库查看执行计划的命令略有差异，但思路一致：先告诉数据库“别真执行，只分析”，然后让它返回执行步骤。
MySQL：使用EXPLAIN
在MySQL中，只需在SELECT语句前加上EXPLAIN即可：
EXPLAIN SELECT * FROM orders WHERE user_id = 1001 AND status = 'paid';执行后你会看到一张结果表，关键字段包括：
- type：访问类型，如const、ref、index、ALL，其中ALL代表全表扫描，通常需要优化。
- key：实际使用的索引名称，为空说明没走索引。
- rows：预估扫描行数，越大越慢。
- Extra：额外信息，出现Using filesort或Using temporary时往往意味着性能隐患。
PostgreSQL：EXPLAIN ANALYZE更进一步
PostgreSQL除了EXPLAIN，还支持EXPLAIN ANALYZE，后者会真正执行SQL并给出实际耗时：
EXPLAIN ANALYZE SELECT * FROM products WHERE category_id = 5;输出中你会看到“Execution Time: 12.4ms”这样的真实数据，比预估更可靠。注意，ANALYZE会触发实际读操作，生产环境慎用。
SQL Server：图形化与T-SQL双管齐下
在SSMS（SQL Server Management Studio）中，可以点击“显示估计的执行计划”按钮，直接看到图形化的执行流程。也可以用命令：
SET SHOWPLAN_ALL ON;
GO
SELECT * FROM customers WHERE city = '北京';
GO这种方式不会执行语句，适合分析复杂存储过程。
Oracle：从AUTOTRACE到DBMS_XPLAN
在SQL*Plus中，开启AUTOTRACE就能看到执行计划：
SET AUTOTRACE ON;
SELECT * FROM employees WHERE department_id = 10;或者使用更现代的方式：
EXPLAIN PLAN FOR SELECT * FROM employees WHERE department_id = 10;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);看懂执行计划的关键点
拿到执行计划后，重点看几个信号：
- 有没有出现全表扫描（Table Scan）？如果有，检查WHERE条件字段是否有索引。
- 表连接顺序是否合理？小表驱动大表通常更高效。
- 是否出现了临时表或排序操作？这些都可能拖慢速度。
举个例子，你发现一条查询本该走user_id索引，但执行计划显示走了全表扫描。一查原因，原来是user_id字段被隐式转换了，比如传了个字符串'1001'而不是数字1001，导致索引失效。
结合业务场景优化
在电商后台查“某个商品的评价”，如果每次都要关联用户表、订单表、评价表，执行计划可能会显示多个Nested Loop或Hash Join。这时你可以考虑是否添加联合索引，或者用冗余字段减少关联。
再比如，报表系统常查时间段数据，如果发现对create_time字段总是全表扫描，那就得确认是否建立了时间字段的索引，尤其是复合索引中的位置是否合理。