N+1 查询排查：ORM 帮你写的代码，正在拖垮 P99

N+1 是后端最经典也最容易被忽略的性能问题。ORM 让“取列表再逐条取关联”写起来很自然，但一次请求可能变成 1 次主查询加 N 次子查询。数据量小时看不出来，列表页一上量，P99 直接飙。

排查方法很直接：打开 SQL 日志，按请求 trace ID 聚合，看一次 HTTP 请求触发了多少条 SQL。如果列表有 50 条，SQL 数量接近 51 条，基本就是 N+1。另一个信号是数据库 QPS 很高但单条 SQL 都很快，说明问题在调用次数，不在单条性能。

修复手段按场景选。第一，预加载关联：ORM 通常支持 include、preload、select_related，一次查询把关联取回。第二，批量查询：先取主表 ID 列表，再用 IN 查关联，应用层组装。第三，DataLoader：适合 GraphQL 或复杂嵌套，把同一层的请求合并成批。第四，冗余字段：对高频只读关联，适当反范式，减少 join。

要注意预加载不是越多越好。一次 join 太多表会导致笛卡尔积和宽结果集，反而慢。按页面实际需要的字段做投影，别 SELECT *。

还有一个隐藏来源是序列化。ORM 对象转 JSON 时懒加载关联，会在序列化阶段触发额外查询。解决方案是在查询层显式加载，或者用 DTO 控制输出字段。

N+1 不是 ORM 的错，是“透明”带来的代价。定期看 SQL 数量，比出事后再优化便宜得多。