首先启用慢查询日志定位执行慢的SQL语句，通过设置slow_query_log、long_query_time等参数记录耗时操作，并使用mysqldumpslow或pt-query-digest分析日志；接着对可疑SQL使用EXPLAIN命令查看执行计划，重点关注type、key、rows和Extra字段，判断是否存在全表扫描或临时排序等问题；然后合理设计索引，为WHERE、ORDER BY、GROUP BY涉及的列创建复合索引并遵循最左前缀原则，避免冗余索引影响写入性能；同时优化SQL写法，避免SELECT *、深层嵌套子查询、大OFFSET分页及在WHERE中对字段进行函数操作；此外选择合适的数据类型和InnoDB存储引擎，主键优先使用自增整数以减少索引分裂，大表可考虑分区策略；最后持续监控SQL性能，利用SHOW PROCESSLIST、Performance Schema等工具跟踪运行状态，定期复查慢查询日志，形成“发现—分析—优化—监控”的闭环流程，核心目标是减少数据扫描量、提高索引命中率、降低资源开销。
SQL语句在MySQL中的执行效率直接影响系统性能，尤其在数据量大、并发高的场景下，优化显得尤为重要。调优不是盲目加索引或改写语句，而是一个有步骤的分析和改进过程。以下是常见的MySQL SQL语句级优化步骤。
1. 启用慢查询日志定位问题SQL
第一步是找出哪些SQL语句执行慢。通过开启慢查询日志，可以记录超过指定时间的SQL语句，便于后续分析。
关键操作：- 在my.cnf中设置：slow_query_log = ON
- 设定阈值：long_query_time = 1（单位：秒）
- 指定日志文件：slow_query_log_file = /var/log/mysql-slow.log
使用mysqldumpslow或pt-query-digest分析日志，找出执行频率高或耗时长的SQL。
2. 使用EXPLAIN分析执行计划
对可疑SQL使用EXPLAIN命令查看其执行计划，了解MySQL是如何执行这条语句的。
- type：连接类型，最好为ref或const，避免ALL（全表扫描）
- key：是否命中索引
- rows：扫描行数，越少越好
- Extra：出现Using filesort或Using temporary通常意味着需要优化
例如：EXPLAIN SELECT * FROM orders WHERE user_id = 100;
3. 合理设计和使用索引
索引是提升查询速度的核心手段，但不合理的索引反而影响写入性能。
建议做法：
- 为WHERE、ORDER BY、GROUP BY涉及的列建立索引
- 使用复合索引时注意最左前缀原则
- 避免过多索引，特别是对频繁更新的表
- 定期检查冗余或未使用的索引（可通过performance_schema查看）
例如，查询WHERE a=1 AND b=2，应建立(a,b)联合索引，而不是单独为a和b建索引。
4. 优化SQL语句写法
有些写法虽然逻辑正确，但效率低下，需调整结构。
常见优化技巧：- 避免
SELECT *，只查需要的字段 - 减少子查询嵌套，能用JOIN尽量用JOIN
- 分页时避免
OFFSET过大，可采用游标方式（如记录上一次ID） - 避免在WHERE条件中对字段做函数操作，如
WHERE YEAR(create_time) = 2023，应改为范围查询 - 使用
IN代替多个OR，但注意IN列表不宜过长
5. 关注表结构与存储引擎
良好的表设计是高性能的基础。
- 选择合适的数据类型，如用
INT不用BIGINT，用VARCHAR(255)而非TEXT（除非必要） - 使用InnoDB引擎，支持事务和行锁
- 主键尽量使用自增整数，避免UUID等随机值导致索引分裂
- 大表考虑分区（如按时间分区），但需评估维护成本
6. 监控与持续优化
优化不是一次性工作。上线后要持续监控SQL性能。
- 结合
SHOW PROCESSLIST查看当前执行的SQL - 使用Performance Schema或第三方工具（如Prometheus + MySQL Exporter）
- 定期复查慢查询日志，发现新出现的瓶颈
基本上就这些。从发现问题到分析执行计划，再到索引和语句优化，每一步都围绕“减少扫描、提高命中、降低开销”展开。坚持这样的流程，多数SQL性能问题都能有效解决。
