政策快报平台刚上线那年，政策数据量只有几十万条，查询速度不是问题。随便一个SQL，怎么写都快。
两年后，数据量突破5000万条，问题开始暴露：列表页越来越慢，后台查询经常超时。explain一看，全是全表扫描。
后来的一年多里，我们做了3轮索引优化，把大部分慢查询从秒级降到了毫秒级。今天复盘这3轮优化的思路和具体操作。
3轮索引优化
第一轮：单列索引（解决最基础的查询）
触发问题：某段时间后台反馈"政策列表加载太慢"，持续了大约一周，多个用户在工作时间反映同样的问题。当时的查询语句是按发布日期倒序取最新20条，执行计划显示全表扫描。
慢查询语句：
sql
SELECT * FROM policies WHERE status = 'published' ORDER BY publish_date DESC LIMIT 20;
执行时间：2.8秒。
问题原因：publish_date字段没有索引。
解决方案：
sql
CREATE INDEX idx_publish_date ON policies(publish_date);优化后执行时间：35毫秒，降低约98.8%。
经验总结： 排序字段必须有索引，这是最基本的索引规则。但单列索引只能解决单条件排序问题，多条件查询时就不够用了。
第二轮：联合索引（解决组合查询）
触发问题：加了按地区的筛选条件后，查询又变慢了。因为筛选条件组合多，单列索引只能命中一个条件。
慢查询语句：
sql
SELECT * FROM policies
WHERE region = '广东' AND status = 'published'
ORDER BY publish_date DESC
LIMIT 20;执行时间：1.5秒。
问题原因：region有索引，但需要回表取publish_date做排序。
解决方案：
sql
CREATE INDEX idx_region_status_publish ON policies(region, status, publish_date);优化后执行时间：28毫秒。
索引字段顺序的选择：等值条件（region、status）放在前面，范围/排序条件（publish_date）放在后面。这符合"最左前缀"原则，且能覆盖ORDER BY排序，避免filesort。
经验总结： 多条件查询需要联合索引。字段顺序很重要：等值查询放前面，范围查询放后面。
第三轮：覆盖索引（解决"回表"问题）
触发问题：后台列表页需要展示政策ID、标题、发布日期、地区，但索引只覆盖了部分字段，查询需要回表取其他数据，增加了额外的I/O开销。
慢查询语句（含select多个字段）：
sql
SELECT id, title, region, publish_date, status
FROM policies
WHERE region = '广东' AND status = 'published'
ORDER BY publish_date DESC
LIMIT 20;执行时间：原本联合索引已能命中，但需要回表取title字段，耗时约120毫秒（含回表I/O）。
问题原因：查询需要的字段不在索引中，需要回表。
解决方案：
sql
CREATE INDEX idx_region_status_publish_cover
ON policies(region, status, publish_date, id, title);优化后执行时间：25毫秒（无需回表，全部从索引读取）。
经验总结： 高频查询可以考虑覆盖索引。索引包含了查询需要的所有字段，不需要回表，查询速度最快。但覆盖索引会增加写入成本和存储空间，仅对高频查询使用。
3条索引经验总结
经验一： 先看执行计划再建索引。执行计划（explain）会告诉你查询走了哪个索引、扫描了多少行、有没有回表、有没有filesort------根据这些信息决定建什么索引，而不是凭感觉乱建。
经验二： 联合索引字段顺序有讲究。等值条件放前面，范围/排序条件放后面。顺序错了，索引可能完全用不上。
经验三： 覆盖索引效果好，但不能滥用。覆盖索引能避免回表，显著提升查询速度，但索引本身也占用存储空间，且每次写入都要更新索引。仅在核心高频查询上使用。
结尾
索引优化不是"建了就完事"。数据量在增长，查询模式在变化，索引策略需要持续调整。定期review慢查询日志，发现新的慢查询就优化，保持系统响应速度。