SQL SELECT查询的执行计划是数据库优化器生成的、用于描述查询语句执行步骤的详细说明，它包含了数据访问方式、表连接顺序、索引使用情况等关键信息，优化执行计划是提升查询性能的核心手段。
如何查看SQL SELECT的执行计划
不同数据库查看执行计划的语法略有差异，以下是常见数据库的实现方式：
MySQL查看执行计划
在SELECT语句前添加EXPLAIN关键字即可查看执行计划：
-- 查看简单查询的执行计划 EXPLAIN SELECT user_id, user_name FROM user_info WHERE age > 18; -- 查看关联查询的执行计划 EXPLAIN SELECT u.user_name, o.order_id FROM user_info u JOIN order_info o ON u.user_id = o.user_id WHERE u.age > 18;
PostgreSQL查看执行计划
使用EXPLAIN或者EXPLAIN ANALYZE命令，后者会实际执行查询并返回真实运行时间：
-- 仅查看执行计划 EXPLAIN SELECT product_id, product_name FROM product WHERE price < 100; -- 查看执行计划并获取实际执行数据 EXPLAIN ANALYZE SELECT product_id, product_name FROM product WHERE price < 100;
执行计划中需要关注的核心指标
分析执行计划时，需要重点关注以下几个指标来判断是否存在性能问题：
- 访问类型（type）：MySQL中该字段表示数据访问方式，
ALL代表全表扫描，性能最差；ref、range、const等代表使用了索引，性能更优。 - 扫描行数（rows）：数据库预估需要扫描的行数，数值越大通常性能越差。
- 额外信息（Extra）：包含
Using filesort（需要额外排序）、Using temporary（使用临时表）等提示，这些通常表示存在可优化的点。 - 成本（cost）：PostgreSQL等数据库会显示查询的执行成本，成本越高说明查询越耗时。
SQL SELECT优化执行计划的常用方法
合理使用索引优化数据访问
索引是优化执行计划最有效的手段之一，需要根据查询条件合理创建索引：
如果查询中经常使用WHERE条件过滤某一列，可以给该列创建普通索引：
-- 给user_info表的age列创建索引，优化age条件查询 CREATE INDEX idx_user_age ON user_info(age);
如果查询需要同时过滤多个列，可以创建联合索引，注意联合索引遵循最左前缀原则：
-- 创建联合索引，支持where age>18 and city='北京'的查询，也支持仅where age>18的查询 CREATE INDEX idx_user_age_city ON user_info(age, city);
需要避免索引失效的场景，比如对索引列使用函数、进行类型转换、使用LIKE '%xxx'左模糊匹配等，这些操作会导致执行计划放弃使用索引而进行全表扫描。
优化查询条件减少扫描范围
尽量缩小查询的扫描范围，避免不必要的全表扫描：
- 不要使用
SELECT *，只查询需要的列，减少数据传输和扫描开销。 - 避免使用
OR连接多个条件，如果多个OR条件无法使用索引，可以拆分成多个查询用UNION连接。 - 对于范围查询，尽量明确边界，比如使用
age BETWEEN 18 AND 30代替age > 18 AND age < 30，部分优化器对BETWEEN的处理更高效。
优化表连接逻辑
多表关联查询时，执行计划中的表连接顺序和连接方式对性能影响很大：
尽量用小表驱动大表，比如使用INNER JOIN时，将结果集更小的表放在前面。如果业务允许，优先使用INNER JOIN代替LEFT JOIN，INNER JOIN的优化器可以选择更优的连接顺序。
连接条件必须使用索引列，避免连接时进行全表扫描：
-- 给order_info表的user_id列创建索引，优化关联查询的连接条件 CREATE INDEX idx_order_user_id ON order_info(user_id);
避免执行计划中的额外开销
如果执行计划的Extra字段出现Using filesort或者Using temporary，需要针对性优化：
对于排序操作，尽量使用索引列排序，避免ORDER BY非索引列导致的额外排序开销：
-- 给create_time列创建索引，优化按创建时间排序的查询 CREATE INDEX idx_order_create_time ON order_info(create_time); -- 该查询可以使用idx_order_create_time索引完成排序，避免filesort SELECT order_id, create_time FROM order_info ORDER BY create_time DESC LIMIT 10;
对于分组查询，尽量使用索引列分组，避免GROUP BY非索引列导致的临时表开销。
执行计划优化的验证方法
每次调整查询语句或者索引后，都需要重新查看执行计划，确认优化是否生效：
优化执行计划是一个迭代的过程，需要结合实际业务查询场景反复调整，不能盲目创建大量索引，过多的索引会影响插入、更新、删除操作的性能。
可以通过对比优化前后的执行计划扫描行数、访问类型、执行成本等指标，判断优化效果，同时可以在测试环境实际执行查询，对比运行时间验证优化是否达到预期。