导读 sql 语句优化的一般步骤核心思路是先定位慢 SQL，再分析执行计划，找出瓶颈点，然后针对性调整 SQL 写法 索引 表结构，最后压测验证优化效果，SQL 变慢本质就是数据库扫描的数据量过大，或者关联排序临时表消耗资源过高，优化不是盲目加索引，很多新手一看到慢查询就直接新建索引，最后索引越来越多，写入性能反而下降，正确的优化顺序一定要先确认业务逻辑，确认这条 SQL 是不是真的需要查询全部数据，能不能减少返回字段，能不能缩小筛选范围，主流 MySQL 数据库主要依靠 explain 执行计划来判断优化方向，重点看 type rows Extra 这些字段，优化完成之后要对比优化前后执行时间扫描行数，确认优化有效，同时还要评估优化对 insert update delete 带来的副作用，整个流程适合业务系统慢查询治理，也适合学习数据库性能调优，不同数据库比如 Oracle SQLServer 虽然执行计划查看方式不一样，但是整体优化逻辑是相通的。

sql 语句优化的一般步骤核心思路是先定位慢 SQL，再分析执行计划，找出瓶颈点，然后针对性调整 SQL 写法 索引 表结构，最后压测验证优化效果，SQL 变慢本质就是数据库扫描的数据量过大，或者关联排序临时表消耗资源过高，优化不是盲目加索引，很多新手一看到慢查询就直接新建索引，最后索引越来越多，写入性能反而下降，正确的优化顺序一定要先确认业务逻辑，确认这条 SQL 是不是真的需要查询全部数据，能不能减少返回字段，能不能缩小筛选范围，主流 MySQL 数据库主要依靠 explain 执行计划来判断优化方向，重点看 type rows Extra 这些字段，优化完成之后要对比优化前后执行时间扫描行数，确认优化有效，同时还要评估优化对 insert update delete 带来的副作用，整个流程适合业务系统慢查询治理，也适合学习数据库性能调优，不同数据库比如 Oracle SQLServer 虽然执行计划查看方式不一样，但是整体优化逻辑是相通的。

优化前置准备

1 开启慢查询日志，把执行耗时超过阈值的 SQL 记录下来，筛选出需要优化的目标 SQL

2 记录优化前基线数据，包含执行耗时 返回行数 扫描行数 CPU 消耗，作为后续对比基准

3 确认业务需求，确认 SQL 查询逻辑是否合理，有没有多余关联表，有没有不必要的排序，确认优化不会改动业务结果

4 准备测试环境，所有优化优先在测试环境验证，不要直接在生产库修改，避免影响线上业务

sql 语句优化的一般步骤详细拆解

第一步 收集慢 SQL，通过慢查询日志 监控平台 业务接口报错，锁定需要优化的 SQL 语句

第二步 执行 explain 查看执行计划，分析关键字段

type 访问类型，const eq_ref ref range index all，all 代表全表扫描，属于重点优化对象

rows 预估扫描行数，数值越大扫描的数据越多

Extra 重点关注 Using filesort Using temporary，代表出现文件排序和临时表，性能消耗很高

第三步 判断瓶颈类型，区分是全表扫描，索引失效，多表 join 顺序不合理，排序分组产生临时表，还是返回字段过多

第四步 优化 SQL 本身写法，优先精简查询，禁止 select 全部字段，只保留业务需要字段，where 条件尽量命中索引，避免对索引字段使用函数运算，避免 like 前置百分号，避免隐式类型转换

第五步 调整索引方案，新增联合索引，遵循最左前缀原则，删除长期无效冗余索引，联合索引顺序把高区分度字段放在前面

第六步 优化多表关联，调整 join 顺序，小表驱动大表，拆分复杂大 SQL，把多层嵌套子查询改成 join，减少嵌套层级

第七步 处理排序分组问题，order by group by 字段尽量使用索引覆盖，消除 Using filesort 和 Using temporary

第八步 测试验证，重新执行 explain，对比扫描行数和执行耗时，确认性能提升，同时测试业务结果和优化前保持一致

第九步 评估副作用，新增索引会增加 insert update delete 维护成本，写入频繁的表不能盲目加大量索引

第十步 上线观察，上线之后持续监控慢查询日志，确认没有新的性能问题，记录优化方案归档

常见索引失效场景表格

写法失效原因优化方式
where date 函数索引字段索引字段参与函数计算改成范围查询，不使用函数
where 字符字段传入数字隐式类型转换参数类型和字段类型保持一致
like 关键词 %前置通配符，无法命中索引使用全文索引或者后置 like
or 连接非索引字段or 一侧无索引导致全表扫描改用 union all
联合索引跳过最左字段违反最左前缀原则调整查询条件顺序

进阶优化补充

数据量特别大的表，单纯优化 SQL 效果有限，可以考虑分表分区，读写分离，缓存层提前缓存热点查询结果，减少数据库直接查询，复杂报表 SQL 可以预聚合，提前生成汇总表，不用每次实时计算，优化的时候还要注意，SQL 优化不能牺牲业务正确性，不能为了提速改变查询结果。

排错要点

优化之后速度没有提升，大概率是统计信息过期，数据库没有更新表统计信息，需要 analyze table 更新统计信息。如果 SQL 本身业务逻辑不合理，比如需要查询千万级全量数据，单纯 SQL 优化收益很低，要从业务层面改造方案。

【常见问题】

问题 1 sql 语句优化的一般步骤里面 explain 主要看什么

回答 1 sql 语句优化的一般步骤里面 explain 主要查看 type rows Extra，重点识别全表扫描，文件排序，临时表这些性能瓶颈，sql 语句优化的一般步骤把 explain 作为核心分析手段。

问题 2 sql 语句优化的一般步骤能不能直接在生产库加索引

回答 2 sql 语句优化的一般步骤不推荐直接在生产库加索引，sql 语句优化的一般步骤要求优先在测试环境验证，确认索引有效并且评估写入开销之后再上线生产。

问题 3 sql 语句优化的一般步骤为什么 select 全部字段要改掉

回答 3 sql 语句优化的一般步骤推荐只查询需要字段，select 全部字段会增加数据传输量，还很难实现覆盖索引，sql 语句优化的一般步骤会优先精简返回字段提升查询速度。

问题 4 sql 语句优化的一般步骤优化之后还要复测吗

回答 4 sql 语句优化的一般步骤优化完成之后必须复测，重新执行 explain 对比扫描行数和耗时，并且校验查询结果，sql 语句优化的一般步骤复测是确认优化成功的必要环节。

【免责申明】

本内容为 SQL 语句优化通用调优流程，不同数据库优化器机制存在差异，生产环境操作前做好备份，优化方案需要结合业务表数据量和访问特征，内容仅用于学习参考，不保证所有场景优化效果。