在数据库日常运维和开发过程中，慢SQL是导致系统性能下降的常见原因，轻则让接口响应变慢，重则可能引发数据库宕机。想要解决慢SQL问题，首先需要准确找到这些存在性能问题的SQL语句，下面介绍几种常用的定位方法。
开启慢查询日志
慢查询日志是数据库内置的功能，能够自动记录执行时间超过指定阈值的SQL语句，是定位慢SQL最直接的方式。以MySQL为例，开启和配置慢查询日志的步骤如下：
查看慢查询日志状态
首先可以查看当前慢查询日志是否开启，以及相关的配置参数：
-- 查看慢查询日志是否开启，ON表示开启，OFF表示关闭 SHOW VARIABLES LIKE 'slow_query_log'; -- 查看慢查询的时间阈值，单位秒，默认是10秒 SHOW VARIABLES LIKE 'long_query_time'; -- 查看慢查询日志的存储路径 SHOW VARIABLES LIKE 'slow_query_log_file';
配置并开启慢查询日志
如果慢查询日志未开启，可以通过如下命令临时开启，重启数据库后会失效，如果需要永久生效，需要修改配置文件：
-- 开启慢查询日志 SET GLOBAL slow_query_log = 'ON'; -- 设置慢查询时间阈值为2秒，执行时间超过2秒的SQL会被记录 SET GLOBAL long_query_time = 2; -- 记录未使用索引的查询，方便排查索引问题 SET GLOBAL log_queries_not_using_indexes = 'ON';
配置完成后，所有执行时间超过2秒的SQL，以及未使用索引的查询都会被记录到指定的慢查询日志文件中，直接查看日志文件就能找到对应的慢SQL。
使用EXPLAIN分析执行计划
找到慢SQL之后，还需要进一步分析SQL的执行过程，这时候可以使用EXPLAIN命令查看SQL的执行计划，了解SQL是如何执行查询的，从而找到性能瓶颈。使用方式如下：
-- 在需要分析的SQL前面加上EXPLAIN关键字 EXPLAIN SELECT * FROM user WHERE age > 20 AND name LIKE '张%';
执行后会返回多个字段，其中几个关键字段的含义如下：
- type：表示访问类型，性能从好到坏依次是system > const > eq_ref > ref > range > index > ALL，出现ALL说明是全表扫描，性能较差
- key：表示实际使用的索引，如果为NULL说明没有使用索引
- rows：表示预估需要扫描的行数，数值越大性能越差
- Extra：额外信息，比如出现Using filesort、Using temporary说明存在排序或者临时表问题，性能较差
通过数据库监控工具定位
除了手动开启日志和分析执行计划，还可以使用数据库自带的监控功能或者第三方监控工具来定位慢SQL。比如MySQL的performance_schema库，里面存储了数据库运行过程中的各种性能数据，可以查询最近执行的慢SQL：
-- 查询执行时间超过1秒的SQL SELECT DIGEST_TEXT, COUNT_STAR, AVG_TIMER_WAIT/1000000000 AS avg_time_sec FROM performance_schema.events_statements_summary_by_digest WHERE AVG_TIMER_WAIT/1000000000 > 1 ORDER BY avg_time_sec DESC LIMIT 10;
另外还有很多可视化的数据库监控工具，比如Prometheus搭配Grafana、Percona Monitoring and Management等，可以实时展示SQL的执行耗时、调用频率等指标，快速定位到耗时高的慢SQL。
定位后的优化方向
定位到慢SQL之后，通常可以从以下几个方向进行优化：
- 检查是否缺少合适的索引，添加或者优化索引
- 优化SQL语句本身，比如避免select *，减少不必要的关联查询，优化where条件
- 调整数据库配置参数，比如缓存大小、连接数等
- 如果是数据量过大导致的查询慢，可以考虑分库分表或者归档历史数据
定位慢SQL是数据库性能优化的基础工作，日常开发中建议定期查看慢查询日志，及时发现和处理性能问题，避免问题积累影响系统稳定性。