3. 数据库查询优化：分析慢查询日志，优化索引设计，使用覆盖索引与复合索引减少回表

在低延迟评分接口中，数据库查询往往是最大的延迟瓶颈。本章聚焦于如何通过系统化的慢查询分析、精准的索引设计以及覆盖索引与复合索引的实战运用，将查询延迟从百毫秒级降至毫秒级。

3.1 慢查询日志分析：定位性能瓶颈

慢查询日志是数据库性能优化的第一手资料。通过分析慢查询日志，可以精准定位哪些 SQL 语句消耗了最多的 I/O 和 CPU 资源。

3.1.1 开启与配置慢查询日志

以 MySQL 为例，推荐的生产环境配置如下：

-- 开启慢查询日志
SET GLOBAL slow_query_log = ON;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow-query.log';
-- 设置阈值：超过 100 毫秒即记录
SET GLOBAL long_query_time = 0.1;
-- 记录未使用索引的查询
SET GLOBAL log_queries_not_using_indexes = ON;

3.1.2 慢查询日志关键指标解读

3.2 索引设计优化：从 B+Tree 到查询路径

索引设计的核心原则是：减少扫描行数，避免回表。B+Tree 索引结构决定了查询效率与索引的字段顺序、选择性密切相关。

3.2.1 索引设计三大原则

1. 高选择性字段前置：将区分度高的字段放在联合索引最左侧，快速过滤数据。
2. 覆盖查询字段：索引中包含查询所需的所有列，避免回表访问聚簇索引。
3. 避免冗余索引：删除重复或未被使用的索引，减少写入开销。

3.2.2 实战案例：评分查询优化

假设评分接口的核心查询如下：

-- 原始慢查询（耗时 320ms）
SELECT user_id, score, level, update_time
FROM user_score
WHERE user_id = 12345 AND status = 1
ORDER BY update_time DESC
LIMIT 1;

通过 EXPLAIN 分析发现：type: ref，rows: 15000，Extra: Using filesort; Using where。这意味着查询扫描了 1.5 万行，且使用了文件排序。

-- 创建复合索引
ALTER TABLE user_score ADD INDEX idx_user_status_time
(user_id, status, update_time DESC, score, level);

-- 优化后查询（耗时 2ms）
SELECT user_id, score, level, update_time
FROM user_score
WHERE user_id = 12345 AND status = 1
ORDER BY update_time DESC
LIMIT 1;

优化后 EXPLAIN 显示：type: ref，rows: 1，Extra: Using index。扫描行数从 1.5 万降至 1 行，且完全使用覆盖索引，无需回表。

3.3 覆盖索引与复合索引：减少回表的实战策略

覆盖索引是指查询所需的所有列都包含在索引树中，无需回表访问聚簇索引。复合索引则是将多个字段组合成一个索引，用于满足多条件查询和排序需求。

3.3.1 覆盖索引的工作原理

InnoDB 的聚簇索引存储了整行数据，而二级索引只存储索引列和主键。当查询列全部在二级索引中时，MySQL 可以直接从索引树返回结果，避免回表操作。

3.3.2 复合索引设计的最佳实践

3.4 索引优化实战流程

以下是一个可复用的索引优化流程，适用于评分接口的数据库查询优化：

1. 采集慢查询：开启慢查询日志，收集 24 小时内的 TOP 10 慢查询。
2. EXPLAIN 分析：对每条慢查询执行 EXPLAIN，关注 type、rows、Extra 列。
3. 识别回表操作：检查 Extra 列是否包含 Using index condition 或 Using where，确认是否存在回表。
4. 设计复合索引：根据查询的 WHERE、ORDER BY、SELECT 列，设计覆盖所有字段的复合索引。
5. 验证效果：再次执行 EXPLAIN，确认 Extra 列出现 Using index，且 rows 大幅减少。
6. 监控与回滚：上线后监控查询延迟和索引使用率，必要时回滚或调整索引顺序。

3.5 常见陷阱与避坑指南

3.6 本章小结