数据库慢查询日志是定位性能瓶颈的第一手资料，直接告诉你哪些SQL语句执行太慢、耗时多少、扫描了多少行数据。面对慢查询，核心实战路径就是三步：从慢日志中精准抓取问题SQL，通过EXPLAIN深入分析其执行计划，然后基于索引优化、查询重写或结构调优来彻底解决它。比如，一条原本需要全表扫描3秒的查询，在添加合适的复合索引并调整JOIN顺序后，执行时间可以缩短到30毫秒以下。

一、慢查询日志的配置与关键信息解读

大多数数据库系统都内置了慢查询日志功能。以MySQL为例，你需要在配置文件（如my.cnf）中设置几个关键参数：long_query_time定义“慢”的阈值（例如1秒），slow_query_log开启日志记录，slow_query_log_file指定日志文件路径。开启后，任何执行时间超过阈值的SQL都会被记录。日志中每条记录都包含几个硬核信息：执行时间（Query_time）、锁定时间（Lock_time）、发送行数（Rows_sent）、扫描行数（Rows_examined）以及具体的SQL语句。分析时，要优先关注那些Rows_examined远大于Rows_sent的查询，这通常是全表扫描或索引使用不当的明显信号。

二、使用EXPLAIN命令深度解析执行计划

抓到慢SQL后，下一步就是用EXPLAIN命令（或EXPLAIN ANALYZE）查看数据库是如何执行这条语句的。执行计划会输出一个表格，其中几个字段是分析核心：type字段表示访问类型，从优到劣大致是const > eq_ref > ref > range > index > ALL，看到ALL就意味着全表扫描，必须优化；key字段显示实际使用的索引，如果为NULL则说明未用索引；rows字段是预估扫描行数，Extra字段包含额外信息，如“Using filesort”（需要额外排序）或“Using temporary”（使用临时表），这些通常也是性能杀手。你需要像侦探一样，结合这些线索判断瓶颈所在。

三、索引优化：从添加、调整到覆盖索引

绝大多数慢查询的根源在于索引缺失或设计不当。优化索引是最高效的手段。首先，确保WHERE子句、JOIN连接条件和ORDER BY/GROUP BY的字段上有索引。对于多条件查询，复合索引的顺序至关重要，应遵循“最左前缀原则”，将区分度最高的字段放在左边。例如，对于查询“SELECT * FROM users WHERE city='北京' AND age>30”，创建索引(city, age)是高效的。更进一步，可以使用覆盖索引，即索引包含了查询所需的所有字段，这样数据库只需读取索引而无需回表，性能提升显著。但索引不是越多越好，维护索引也有成本，需平衡读写比例。

四、SQL语句重写与结构调优实战技巧

有时，仅靠索引不够，需要动刀重写SQL本身。常见技巧包括：

(1)避免使用SELECT *，只查询需要的列，减少数据传输和I/O；

(2)将复杂的子查询转化为JOIN操作，通常JOIN的优化器路径更优；

(3)谨慎使用LIKE通配符前缀查询（如LIKE '%keyword%’），这会导致索引失效，可考虑全文检索方案；

(4)对大分页查询进行优化，例如用“WHERE id > [上一页最大ID]”替代“LIMIT 100000, 20”。此外，审视数据库表结构设计，如对过长的字段进行拆分、选择合适的数据类型，也能从根本上提升性能。

五、进阶：连接池、参数调优与系统级监控

当单条SQL优化到极致后，性能瓶颈可能上升到系统层面。此时需关注：

(1)数据库连接池配置，合理设置最大连接数，避免连接耗尽或上下文切换过度；

(2)关键内存参数，如InnoDB缓冲池大小，应尽可能设置得大以容纳热点数据；

(3)定期进行统计信息更新，确保优化器能生成准确的执行计划。同时，建立系统级的监控体系，持续观察QPS、慢查询率、连接数等指标，将性能优化从“救火”变为主动的常态化工作。

六、一个完整的实战案例剖析

假设我们有一个订单表orders（约1亿行），慢日志中捕获到一条查询：“SELECT customer_id, SUM(amount) FROM orders WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31' GROUP BY customer_id HAVING SUM(amount) > 1000”，执行时间长达12秒。首先使用EXPLAIN分析，发现type为ALL（全表扫描），key为NULL，Extra显示“Using temporary; Using filesort”。问题很明显：它在进行全表扫描并创建了临时表进行分组和排序。优化方案：在create_time和customer_id上创建复合索引(create_time, customer_id, amount)，这样索引可以覆盖WHERE条件并包含分组和聚合所需的全部数据，实现索引覆盖扫描。优化后，EXPLAIN显示type变为range，key使用了新索引，Extra中的临时表和文件排序消失，查询时间降至0.8秒。

-- 优化前
EXPLAIN SELECT customer_id, SUM(amount) FROM orders WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31' GROUP BY customer_id HAVING SUM(amount) > 1000;

-- 添加覆盖索引
CREATE INDEX idx_cover ON orders(create_time, customer_id, amount);

-- 优化后再次分析
EXPLAIN SELECT customer_id, SUM(amount) FROM orders WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31' GROUP BY customer_id HAVING SUM(amount) > 1000;

这个案例清晰地展示了从日志抓取、计划分析到索引优化落地的完整闭环。数据库性能优化是一门结合了严谨分析与工程实践的技艺，核心思想永远是：让数据查找的路径尽可能短、尽可能直接。通过持续地分析慢查询日志并重写低效执行计划，你可以系统地提升整个数据库应用的响应速度与稳定性。