从5秒到50毫秒：政策快报平台的慢查询优化实战

2024年有一个月政策快报平台的接口响应时间持续恶化。列表页从200ms涨到1.5秒详情页从100ms涨到800ms。用户开始抱怨“加载慢”“转圈圈”。查了一圈发现根源是数据库慢查询。好几个SQL执行时间超过3秒最慢的一个接近5秒。后来我们用了一个多月优化了十几个慢查询接口响应时间降到了50-100ms。今天复盘几个典型的优化案例。3个典型的优化案例案例一政策列表查询这是最常用的查询也是压力最大的。优化前的SQLSELECT * FROM policies WHERE status published ORDER BY publish_date DESC LIMIT 20 OFFSET 0;看起来很简单但执行计划显示它走了全表扫描——因为publish_date字段没有索引。表里有几百万条政策数据全表扫描一次需要2-3秒。解决方案给publish_date加索引。加上之后查询走了索引时间从3秒降到了50ms。教训排序字段必须建索引。这是最基本的优化但也是最容易被忽略的。案例二按地区筛选查询这个查询的问题更隐蔽。sqlSELECT * FROM policies WHERE region 广东 AND status published ORDER BY publish_date DESC LIMIT 20;执行计划显示它用了region索引但扫描了5万多行。原因是地区状态排序三个条件同时生效但索引只覆盖了地区。解决方案建联合索引(region, status, publish_date)。三个条件都覆盖查询时间从1.2秒降到了30ms。教训多条件查询联合索引比单列索引更有效。顺序很重要等值条件放前面范围条件放后面。案例三热门政策统计查询这个查询是用来做“热门政策排行”的。sqlSELECT policy_id, COUNT(*) as view_count FROM policy_views WHERE view_date 2025-01-01 GROUP BY policy_id ORDER BY view_count DESC LIMIT 10;问题在于policy_views表有几千万条数据按日期筛选后还要分组排序执行时间超过3秒。解决方案做了一张“政策每日浏览量”汇总表每天定时计算一次。查询的时候直接读汇总表不查明细表。优化前3秒。优化后20ms。教训不是所有查询都适合“实时算”。高频、大范围统计类查询预计算比实时计算更合适。优化的3条原则原则一先看执行计划再改代码。explain命令是SQL优化的第一工具。看懂执行计划才能知道瓶颈在哪。原则二索引不是越多越好。每个索引都会增加写入成本。覆盖常用查询就够了不要为了所有查询都建索引。原则三数据量大了之后预计算比实时计算更可靠。实时统计查询在数据量小的时候很快数据量一大就容易出问题。提早设计汇总表或缓存策略可以避免后期被动优化。结尾慢查询优化没有“一步到位”。数据量在增长慢查询会不断出现。持续监控、定期复盘、及时优化是保持系统稳定运行的常态工作。