你的应用很快，因为数据库里几乎没数据

有个场景越来越常见。用AI辅助写出来的应用，测试阶段点哪都快，上线第一天，列表页转圈转到用户直接关掉。

问题通常不在服务器，也不在数据库配置。在代码里。

先看一张图。

这段TypeScript先查出所有订单，然后for循环遍历每一条，在循环体里单独查一次对应的用户。逻辑清楚，读起来也顺。20条测试数据跑下来，响应时间几乎为零。

这个模式有个名字，叫N+1查询。1次查询拿列表，N次查询补关联数据。20条数据是21次数据库往返，感觉不出来。1万条数据就是10001次。每次往返哪怕只算1毫秒，也是10秒。真实环境里还有网络延迟、连接池排队、索引没建好，实际数字只会更难看。

有开发者把这件事总结得很直接：你的应用快，是因为你的数据库几乎是空的。测试数据上的速度不是速度，是一张账单，等第一个真实用户来了才寄到。

AI生成代码特别容易踩这个坑。让Claude Opus 5.5写一个带关联数据的列表接口，它经常给你一个循环，循环里查库。原因也不复杂：逐条处理符合人的直觉，模型生成时一行一行往下想，写出来的就是一行一次查询。测试的时候数据少，谁也不会发现。等数据量上来，应用在发布第一天挂掉，N+1是排得上号的原因。

有个提示词思路值得存下来。让模型自己去找循环里的查询：

Find every place this code runs a query inside a loop, or fires one per item while rendering a list, the N+1 pattern. For each, show the file and how many queries it fires for 100 items, then rewrite the worst one into a single query. Show me the diff first.

翻译过来是：找出所有在循环里发查询、或者在渲染列表时逐项触发查询的地方，也就是N+1模式。每一处标出文件和100条数据时会发多少次查询，然后把最严重的那处改写成单次查询，先给我看diff。

关键是最后一句。先看diff再动手，不然模型可能顺手改一堆别的东西。

这段提示词解决不了所有性能问题，但它能把一类最隐蔽、最晚爆发的问题提前找出来。数据库空着的时候，什么代码都快。真正的问题是，你什么时候才会发现它不快。