午餐高峰期，小程序卡成幻灯片
河西区小白楼附近一家连锁快餐品牌，2023年底上线了自己的点餐小程序。门店12家，日均订单大概800到1000单。平时还行，一到工作日午餐高峰期（11点半到12点半），小程序就开始抽风。顾客点进菜单页要等三四秒，提交订单经常转圈超时。最离谱的一次是2024年3月的一个周五，高峰期一小时内有47个订单因为超时被取消，粗略算下来当天直接损失了将近3000块的营业额。
他们的技术合伙人找到我们，说后端接口响应太慢，想加服务器。我们看完代码后发现，根本不是服务器的问题，是代码写得太随意了。8核16G的云服务器，CPU使用率才30%，但接口平均响应时间1850毫秒。问题全在代码逻辑上。
三个策略，每个都管用
第一个问题：数据库查询没加索引。他们最核心的商品查询接口，每次请求要对一张17万条记录的商品表做全表扫描。加了一个联合索引后，查询时间从620ms直接降到了23ms，降幅超过96%。就这么一个三五分钟的操作，效果立竿见影。第二个问题：N+1查询。获取某个分类下的商品列表时，先查分类再循环查每个商品的详情，如果一个分类下有30个商品，就要执行31次数据库查询。改成JOIN查询后，31次查询合并成1次，接口总耗时从890ms降到了180ms。
第三个策略是加缓存。菜单数据、分类数据这些变化频率很低的，每次请求都去查数据库纯粹是浪费。我们在应用层加了Redis缓存，菜单数据缓存30分钟，接口响应直接从数据库查询的180ms变成缓存的8ms。缓存这点事说起来简单，但很多团队就是不做，或者做了但过期策略没设好，导致缓存跟实际数据不一致。
改完后的效果和数据
这三个优化做完，平均接口响应时间从1850ms降到了420ms，下降了77%。高峰期的订单取消率从原来的约6%降到了不到1%。服务器还是原来那台，配置没变，也没多花一分钱。说白了，很大一部分性能问题都不是硬件不够，是代码写得糙。他们团队后来把这次优化的经验整理成了内部规范，新接口上线前必须通过性能审查——要求核心接口响应时间不超过500ms。三个月后复查，12个小程序接口全部达标。这件事的教训很简单：开发初期多花两天做好查询优化和索引设计，比上线后返工省十倍时间。别偷这个懒。