4. 慢查询优化基础：EXPLAIN 执行计划解读与索引优化原则
慢查询是数据库性能劣化的核心诱因，也是触发 Circuit Breaker 降级的常见上游故障。本章从执行计划解读与索引设计两个维度，建立慢查询优化的系统化方法。
4.1 EXPLAIN 执行计划核心字段解读
MySQL 的 EXPLAIN 命令用于展示 SQL 语句的执行计划，是定位慢查询的第一工具。以下为关键字段及其业务含义：
| 字段 | 含义 | 慢查询典型值 |
|---|---|---|
| id | 查询中 SELECT 的标识符，id 越大越先执行 | 多个高 id 值表示子查询嵌套过深 |
| select_type | 查询类型：SIMPLE / PRIMARY / SUBQUERY / DERIVED | SUBQUERY 或 DERIVED 通常需要优化 |
| table | 访问的表名或别名 | — |
| type | 访问方法，性能从好到差依次为： system > const > eq_ref > ref > range > index > ALL |
ALL（全表扫描）是慢查询首要标志 |
| possible_keys | 可能使用的索引列表 | 为 NULL 表示无可用索引 |
| key | 实际使用的索引名称 | 为 NULL 表示未使用索引 |
| rows | 预估扫描的行数 | 数值越大，查询越慢 |
| Extra | 附加信息，常见值： Using index / Using where / Using filesort / Using temporary |
Using filesort 或 Using temporary 是性能瓶颈信号 |
实战判断口诀： type 看 ALL，key 看 NULL，rows 看大数，Extra 看 filesort/temporary。四者任一异常，即需索引优化或 SQL 改写。
4.2 索引优化核心原则
索引设计直接影响查询执行路径。以下为经过生产验证的六条核心原则：
- 最左前缀原则：联合索引 (a, b, c) 只对 a、(a,b)、(a,b,c) 的查询条件有效；跳过左侧列会导致索引失效。
- 高选择性列前置：将区分度高的列放在联合索引左侧，减少扫描范围。
- 覆盖索引优先：索引包含查询所需的所有列，避免回表（Using index）。
- 避免索引列上做计算：
WHERE DATE(create_time) = '2024-01-01'会使索引失效，应改为WHERE create_time >= '2024-01-01' AND create_time < '2024-01-02'。 - 控制索引数量：单表索引建议不超过 5 个，过多索引会拖慢写入和更新。
- 冗余索引清理：索引 (a,b) 已包含 (a) 的功能，应删除单列索引 (a)。
案例： 某订单查询慢 SQL：
SELECT * FROM orders WHERE status = 1 ORDER BY create_time DESC LIMIT 20。EXPLAIN 显示 type=ALL, rows=500000, Extra=Using filesort。优化方案：创建联合索引 (status, create_time)，type 变为 ref，rows 降至 200，Extra 变为 Using index condition，查询耗时从 2.3s 降至 0.02s。
4.3 EXPLAIN 与索引优化的协同分析流程
以下 SVG 图展示了从慢查询日志到索引优化的完整分析链路：
4.4 常见索引失效场景与排查清单
以下为生产环境中高频出现的索引失效场景，建议作为慢查询排查的检查清单：
| 场景 | 错误写法示例 | 优化写法 |
|---|---|---|
| 索引列参与运算 | WHERE id + 1 = 100 |
WHERE id = 99 |
| 隐式类型转换 | WHERE phone = 13800138000（phone 为 varchar） |
WHERE phone = '13800138000' |
| LIKE 前置通配符 | WHERE name LIKE '%张三' |
WHERE name LIKE '张三%' 或使用全文索引 |
| OR 条件未全部索引 | WHERE a = 1 OR b = 2（仅 a 有索引） |
拆分为 UNION 或为 b 也建索引 |
| 联合索引跳过左侧列 | 索引 (a,b,c)，条件 WHERE b = 1 AND c = 2 |
调整索引顺序为 (b,c) 或补上 a 条件 |
| NOT IN / <> 操作 | WHERE status <> 1 |
改为 WHERE status IN (0,2,3) 或业务逻辑反转 |
注意： 索引优化并非万能。当单表数据量超过千万级时，即使使用索引，深度分页（如
LIMIT 100000,20）仍可能产生大量回表 I/O。此时需结合分库分表或搜索引擎（Elasticsearch）做架构级优化。
4.5 索引设计决策树
以下 SVG 图展示索引设计时的决策路径，帮助开发者在不同查询模式下快速选择索引策略：
4.6 慢查询优化效果量化指标
优化完成后，建议通过以下指标量化效果，并与优化前进行对比：
- 扫描行数（rows）：优化后应降低 1~3 个数量级。
- 查询耗时（Query Time）：目标降至 100ms 以内。
- type 级别：从 ALL 提升至 ref 或 range 为合格，提升至 const 或 eq_ref 为优秀。
- Extra 状态：消除 Using filesort 和 Using temporary。
- QPS 提升：优化后数据库整体吞吐量应提升 2~10 倍。
核心结论： EXPLAIN 是慢查询优化的“听诊器”，索引是“手术刀”。只有将两者结合，才能精准定位问题并实施有效优化，为后续的 Circuit Breaker 降级策略提供稳定的数据库底座。