数据库索引调优：从 EXPLAIN 开始
2 分钟1 条评论
慢查询治理是后端工程师的日常。大多数"数据库太慢"的问题，最后都归结为一个词：索引。
先看执行计划，再动手#
拿到慢查询，第一反应不是加索引，而是看执行计划：
EXPLAIN ANALYZE
SELECT id, title FROM posts
WHERE category_id = 'tech' AND published_at IS NOT NULL
ORDER BY published_at DESC
LIMIT 10;
重点看三件事：扫描方式（Seq Scan 还是 Index Scan）、扫描行数与返回行数的比值、排序是否落盘。
复合索引的列序#
复合索引遵循"最左前缀"原则。设计列序的经验公式：
- 等值条件的列放前面；
- 范围条件的列放后面；
- 排序列紧跟范围列（或者干脆用覆盖索引扛住排序）。
比如上面那条查询，(category_id, published_at DESC) 就是一个理想的复合索引：等值在前、排序在后，LIMIT 10 时只需要读 10 行。
不要忘了写入成本#
索引不是免费的。每个索引都会拖慢写入、占用存储，过于激进的索引策略会让 OLTP 场景雪崩。
| 指标 | 健康值 | 危险信号 |
|---|---|---|
| 索引命中率 | > 99% | < 95% |
| 单表索引数 | ≤ 5~6 | 十几个起步 |
| 无人使用的索引 | 定期清理 | 越积越多 |
小结#
调优的顺序永远是：测量 → 定位 → 最小改动 → 复测。EXPLAIN 是起点，也是终点——改完之后再用它确认，而不是靠感觉。