Vibe Coding 数据库查询审查：用真实计划抓住 N+1 与基数误判

一段 ORM 代码可能只写了五行，却为列表中的每一项追加一次作者查询；另一段“优化”为一个巨大 join，在一对多关系上复制父行并把排序推到磁盘。代码审查若只看抽象 API，很难判断数据库实际执行了几次、读取多少行以及估算为何选中当前路径。AI 还可能根据表名建议索引，却不知道真实数据分布和写入代价。

N+1 查询问题说明现象，PostgreSQL 统计与计划器介绍基础机制。本篇不再做通用解释，而是建立 Vibe Coding 改动门：从一个用户请求捕获真实 SQL 族，再用增长实验和执行计划证明成本没有随结果数意外放大。

先冻结用户场景和数据分布

选择具体路径，例如“管理员打开含作者与最近评论的 50 条文章”。记录分页、排序、权限、过滤条件、返回字段和事务边界。夹具至少有空、小、典型和高扇出 cohort，并保留数据相关性：均匀生成的一万行无法代表少数租户占据大部分记录、热点状态集中在近期日期的生产形态。

合成数据不含真实个人信息，但要固定生成器版本、seed、schema migration 和统计信息更新时间。分别记录冷暖缓存结果，不能把数据库刚重启的一次值与已预热基线比较。性能门使用受控测试库或经批准的脱敏快照，不在生产主库随意运行分析型命令。

预先写接受条件：请求查询数随父记录数是常数、有界批次还是线性；返回行和业务实体如何对应；允许的延迟与读取预算；必须保持的锁和一致性语义。先定义函数形状比先写“最多 20 条 SQL”更重要，因为分页从 10 增到 100 时固定阈值可能掩盖 N+1。

从 ORM 调用还原实际 SQL 清单

在请求边界给所有数据库调用关联同一场景与 trace，记录规范化语句指纹、调用次数、持续时间、返回行、错误和连接等待。参数值默认不进普通日志，尤其是 token、自由文本和个人字段；只保留批准的分桶或合成测试值。OpenTelemetry 数据库语义约定可以统一 span 属性，但具体驱动的字段支持要按版本验证。

让同一场景分别返回 1、10、50、100 个父实体，比较查询指纹计数。某条 relation 查询随父项一比一增长就是直接证据；不要因每条都低于 2 毫秒而接受，因为网络往返、连接池和并发请求会放大总成本。pg_stat_statements 能聚合规范化语句的 calls 与执行统计，适合发现整体热点，但聚合窗口无法单独证明哪一个请求触发了调用，需与请求 trace 交叉验证。

还要捕获懒加载、序列化和模板渲染阶段。数据访问可能在 controller 返回后才发生，单测只统计 service 内调用会漏掉。批量加载器则检查 batch key 是否包含租户、权限和事务上下文，不能为了减少 SQL 把不同安全域合并。

用计划解释单条 SQL 为什么变慢

先运行不执行语句的 EXPLAIN 检查估算，再对受控 SELECT 使用 EXPLAIN (ANALYZE, BUFFERS) 获取实际行和缓冲信息。PostgreSQL 官方文档明确说明 ANALYZE 会实际执行语句；对写入、触发器或外部副作用不能当作只读解释，应在隔离环境用安全方案并由数据 owner 审核。

逐节点比较 estimated rows 与 actual rows、loops、过滤丢弃、排序方法、扫描方式和缓冲读取。估算偏差可能来自统计过旧、列相关性、参数分布或表达式，不能看到顺序扫描就自动加索引。小表顺序扫描可能合理，低选择性索引也可能增加随机读取。

准备语句还可能在通用计划与特定参数计划之间取舍。测试要覆盖热点与长尾参数，并记录实际绑定分桶；只用一个 ID 得到的快计划不能证明所有租户。更新统计或增加扩展统计属于独立候选变更，需要证明对其他关键查询没有负面影响。

比较修复方案的完整代价

消除 N+1 可以使用 join、预加载、分批 IN 查询或请求级 loader。Join 可能造成行爆炸与重复传输；超大 IN 列表会触及参数和计划成本；loader 需要清楚缓存生命周期；预加载可能取回未使用大字段。每个候选在同一数据矩阵测查询数、数据库时间、传输行、应用内存和正确性。

新增索引同时计算写放大、存储、构建与锁风险，并验证查询确实采用它。投影只取需要列，分页使用稳定排序；但不能为性能删除权限谓词、事务锁或一致性检查。用户故事到关系模型中的不变量仍是硬约束。

测试分层：组件或仓储测试断言 query-count growth，集成测试在真实数据库验证 SQL 与事务，集成测试边界防止用同一 ORM mock 证明自己；负载阶段再观察连接池、锁和尾部延迟。每层失败说明不同问题，不能用一次本机 benchmark 全部替代。

最终报告绑定代码提交、migration、数据集摘要、统计水位、场景、查询清单、计划和选择理由。回归时先找 query family、基数和计划变化，再决定改代码、统计还是索引。结果进入编程 Agent 改动验证门。

数据库审查的目标不是让所有查询都用索引，而是证明一次用户任务的查询次数有界、计划与真实基数相符、优化没有跨越正确性边界。有了这组证据，Vibe Coding 才能生成数据访问代码，而不会把复杂度藏在 ORM 的一个属性读取里。