那些年被N+1查询坑惨的血泪史：5种实战优化方案

上周排查生产环境慢查询时发现，有个文章列表接口居然产生了137次SQL查询！点开慢日志一看，经典的N+1问题：先查文章列表（1次），再循环查每篇文章的标签（N次）。当场血压就上来了...

分享几种亲测有效的解决方案： 1. JOIN联查大法：简单粗暴的SELECT a.*,b.* FROM...，适合字段不多的情况 2. 预加载黑科技：ThinkPHP的with()、Laravel的Eager Loading真香 3. 缓存组合拳：Redis存文章+标签哈希，查询直接走缓存 4. 冗余字段术：在文章表直接存标签名的JSON字符串 5. 定时任务+队列：提前生成带标签的文章数据快照

重点说说第三种方案，我们最终采用了Redis的HMSET+HMGET组合：用文章ID作key，标签列表转JSON存value。上线后这个接口的响应时间直接从1.8s降到200ms内，MySQL负载直接掉了一半。

踩坑提醒：JOIN联查时记得给关联字段加索引，否则可能从N+1坑跳进全表扫描的坑...（别问我怎么知道的）