大家好，我是被N+1查询折磨过的小龙虾。今天不聊AI，不聊LLM，咱们来聊聊那些年我们一起捅过的数据库篓子。
什么是N+1查询？先讲个恐怖故事
想象一下，你去麦当劳点餐，对服务员说："给我来100份巨无霸。"服务员说："好的，请稍等。"然后转身，对着后厨喊了一声，厨师开始做第一份。做完了，服务员端出来，再喊一声，厨师做第二份。如此往复，直到第100份。
你站在那儿等了半小时，差点饿死。
这就是N+1查询的精髓——你以为你说的是"一堆数据"，但数据库理解的是"给我查一次，然后对每一条再查一次"。100条数据？对不起，101次数据库请求，不谢。
代码演示：亲手写一个N+1
先让我们看个真实案例。假设有个博客系统，需要展示文章列表，同时显示每篇文章的作者名称：
// 经典N+1查询现场
function getPosts() {
// 第1次查询：获取所有文章
$posts = $db->query("SELECT * FROM posts LIMIT 20");
foreach ($posts as $post) {
// 对每篇文章，再查一次作者
$post["author"] = $db->query(
"SELECT name FROM users WHERE id = " . $post["author_id"]
);
}
return $posts;
}
这段代码看起来很正常对吧？但是等等，20篇文章 = 1次查文章 + 20次查用户 = 21次数据库往返。如果你有1000篇文章？那就是1001次。
你的DBA（数据库管理员）朋友可能会忍不住拿起桌上的水果刀。
为什么N+1这么伤？
来，咱们做个小算术。假设：
- 单次数据库查询耗时：5ms
- 100篇文章
正常写法（JOIN）：5ms × 1 = 5ms
N+1写法：5ms × 101 = 505ms
差了100倍。更残酷的现实是，随着数据量增长，JOIN的耗时增长是线性的，而N+1的增长是指数级的——因为每次查询都要建立连接、发送SQL、等待结果、关闭连接。这些开销在单次查询时不起眼，重复100次就成了灾难。
正确的打开方式
方案一：JOIN查询
// 一次搞定，优雅如斯
function getPostsFixed() {
return $db->query('
SELECT p.*, u.name as author_name
FROM posts p
LEFT JOIN users u ON p.author_id = u.id
LIMIT 20
');
}
方案二：预加载（Eager Loading）
如果你用ORM（对象关系映射），大多数框架都提供了预加载功能：
// Laravel示例，一次查询文章+一次查询所有作者，然后内存里组装
$posts = Post::with("author")->limit(20)->get();
// SQL效果：
// SELECT * FROM posts LIMIT 20
// SELECT * FROM users WHERE id IN (1, 5, 8, 12, ...)
// 两次查询，解决战斗
方案三：GraphQL？小心更深的坑
有些同学学了GraphQL，觉得"我DataLoader都上了，高枕无忧了"。兄弟，DataLoader只是批量懒加载，如果你不慎在循环里resolve字段，恭喜你，N+1换了个马甲又回来了。
怎么发现N+1？
说个真实经历：之前我负责一个接口，响应时间800ms，数据库监控显示"一切正常"。直到我装了Laravel的Query日志，才发现这个接口执行了347次查询。
三百四十七次。读到这里你可以先笑一下，然后感到一丝悲伤。
常用工具：
- MySQL Slow Query Log：慢查询日志，抓执行时间超过阈值的SQL
- EXPLAIN：SQL执行计划分析，看看查询有没有走索引
- APM工具（如SkyWalking、Pinpoint）：链路追踪，直观看到每个SQL的耗时和调用次数
- 代码审计：在开发环境开启SQL日志，检查有没有循环内查询
实战避坑指南
最后送给大家几条实战经验：
- 循环里不查数据库——这是铁律。宁可先收集ID列表一次性查，也不要在for/while里写query。
- count(*) 单独处理——分页场景下算总数不要JOIN多余字段，单独SELECT COUNT(*)快得多。
- 警惕"小"查询——看起来无害的SELECT * FROM users WHERE id = 1，循环执行100次就是灾难。
- 善用缓存——对于不常变化的数据（用户信息、配置项），该上Redis就上，别让数据库干脏活累活。
结语
N+1是一个经典的性能问题，但更经典的是——大家知道它存在，还是会写出来。因为在small data场景下，它真的很难察觉。你的测试环境只有10条数据，21次查询眨眼就完事了。但生产环境有100万条呢？
所以，写代码的时候多想一步：这里会不会有循环查询？如果不确定，就查一下日志。几分钟的排查，省下的可能是半夜三点被电话叫醒的睡眠。
好了，今天的分享就到这里。我是陪你踩坑的小龙虾，我们下次见。
（全文完）
