数据库审查（DB Review）

数据库问题的修复成本随阶段指数增长：代码审查 < migration 审查 < 上线后排查 < 数据修复。 尽早发现，尽早修复。

第一步：确定审查范围和模式

收到审查请求
  │
  ├─ 代码审查模式（改了数据库相关代码）
  │   └─ 检查 SQL 质量 + 查询性能 + 锁风险
  │
  ├─ Migration 审查模式（新增/修改 migration 文件）
  │   └─ 检查安全性 + Schema 漂移 + 回滚方案
  │
  └─ 全量审查（上线前 / 用户主动要求）
      └─ 代码审查 + Migration 审查 + Schema 一致性

技术栈识别

自动检测项目使用的数据库和 ORM：

第二步：代码审查 — SQL 质量与性能

检查维度 1：慢 SQL 模式

逐条检查以下反模式，对每个发现标注风险等级：

审查方法：

1. 搜索所有 SQL 语句（原生查询、ORM 的 raw query、query builder）
2. 对每条 SQL 判断是否命中上述反模式
3. ORM 调用也要检查——findAll() 没加条件等价于 SELECT * 全表扫描

检查维度 2：N+1 查询

这是 ORM 项目最常见的性能杀手。

# 反模式：循环中查询
users = User.findAll()
for user in users:
    orders = Order.findAll({ where: { userId: user.id } })  # N 次查询

# 正确：预加载/JOIN
users = User.findAll({ include: [Order] })  # 1 次查询

检查方法：

1. 搜索循环体内的数据库调用（for/forEach/map 中的 find/query/select）
2. 检查 ORM 的关联查询是否使用了 eager loading（include/joinedload/with）
3. 检查 GraphQL resolver 中的数据加载是否使用了 DataLoader

检查维度 3：锁表风险

以下操作在大表上可能导致长时间锁表：

审查方法：

1. 检查 migration 文件中的 ALTER TABLE 操作
2. 评估目标表的数据量（如果能拿到）
3. 大表（>10 万行）的 DDL 操作标记为高风险

检查维度 4：索引审查

审查方法：

1. 读取 schema/migration 中的索引定义
2. 对照查询语句的 WHERE/JOIN/ORDER BY 检查索引覆盖
3. ORM 的 @Index()/index: true 也要检查

检查维度 5：事务与并发

第三步：Migration 审查 — 安全性与一致性

3.1 破坏性操作检查

以下操作不可逆或有数据丢失风险，必须标记为高风险：

审查方法：

1. 逐行读 migration 文件，标记所有 DROP/RENAME/ALTER 操作
2. 每个破坏性操作必须有对应的回滚方案（down migration）
3. 检查 down migration 是否真的能回滚（不是空函数）

3.2 Schema 漂移检测

这是你反复踩坑的问题：本地和服务端 schema 不一致、缺字段。

漂移来源：

1. 手动改了数据库但没写 migration（最常见）
2. migration 执行顺序不一致（分支合并后）
3. migration 只跑了一半（报错后手动修了但没记录）
4. ORM 的 model 定义和 migration 不同步
5. 多人开发时 migration 文件冲突

检查流程：

Step 1: 收集当前 Schema 定义来源
  ├─ ORM model/entity 定义（代码中的"应该是什么"）
  ├─ Migration 文件链（"变更历史"）
  └─ 数据库实际状态（如果能连接）

Step 2: 交叉比对
  ├─ Model vs Migration：model 里的字段/类型/约束是否都有对应的 migration？
  ├─ Migration 完整性：migration 链是否连续？有没有遗漏？
  └─ 新增字段检查：最近加的字段有 migration 吗？默认值/可空设置对吗？

Step 3: 输出不一致清单
  每条记录：字段名、model 中的定义、migration 中的定义、差异描述

具体检查项：

3.3 回滚方案检查

每个 migration 必须有可执行的回滚方案：

3.4 Migration 最佳实践

第四步：风险分级与输出

风险等级

输出格式

快速审查（终端输出）：

## DB Review 结果

🔴 高危 x N | 🟡 中危 x N | 🟢 低危 x N

### 高危
1. [锁表风险] migrations/20260409_add_index.sql:15 — 大表加索引未用 CONCURRENTLY
   → 修复：`CREATE INDEX CONCURRENTLY idx_users_email ON users(email);`

### 中危
1. [N+1] src/services/order.ts:42 — 循环内查询用户信息
   → 修复：使用 include/joinedload 预加载

### Schema 漂移
- ⚠️ User.phone: model 中存在(String, optional)，但无对应 migration
- ⚠️ Order.discount: model 类型 Decimal，migration 中为 Float

完整审查时，生成报告到 docs/audits/YYYY-MM-DD-db-review.md。

与其他 skill 的衔接

代码开发中
  │
  ├─ 改了数据库代码？→ task-finish 自检时提示跑 db-review（代码审查模式）
  ├─ 新增 migration？→ 提交前跑 db-review（migration 审查模式）
  │
  ↓ 上线前
  ├─ security-audit 审查注入防护（SQL 注入维度）
  └─ db-review 全量审查（Schema 漂移 + 锁表 + 性能）

• perf-profiling：发现 DB 慢查询后，交给 db-review 做 SQL 层面的深度分析
• security-audit：SQL 注入是安全问题，由 security-audit 负责；查询性能是 db-review 负责
• task-finish：改动涉及 migration 文件时，提示跑 db-review

注意事项

• 先理解业务再审查：脱离业务的索引建议是无意义的。先搞清楚查询频率和数据量
• 小表不教条：几百行的配置表不需要纠结索引优化
• ORM 不是借口：ORM 生成的 SQL 也可能很烂，必要时看生成的实际 SQL
• 环境差异：本地 SQLite + 生产 PostgreSQL 时，migration 语法差异是漂移的常见来源
• 不替代 DBA：复杂的分库分表、主从延迟等架构级问题需要 DBA 介入