Prisma 在生产环境踩过的那些坑

开发阶段 Prisma 用得有多爽，生产环境就可能有多措手不及。这篇盘点我在生产环境实际踩过的五个坑。

1. 连接数超限

每个 Prisma 实例默认开 CPU 核数 × 2 + 1 个连接。Node 服务多起几个实例，PostgreSQL 默认 100 个连接上限很快就见底，报错是标准的 Timed out fetching a new connection from the connection pool。

解法：显式压低每个实例的池子，并在数据库前面挂 PgBouncer。

DATABASE_URL="postgresql://user:pass@host:5432/db?connection_limit=5&pool_timeout=10"

2. 交互式事务默认只有 5 秒

$transaction(async (tx) => {...}) 默认 5 秒超时。里面只要混进一个慢查询或者外部 HTTP 调用，就会莫名超时。事务里只放数据库操作，外部调用挪到事务外，这个原则务必守住。

3. 大表迁移锁表

prisma migrate 改列类型时会对表加锁。数据量大的表要挑业务低峰操作，必要时分批处理。

4. JSON 字段查询

PostgreSQL 下 Json 字段的过滤写法不如原生 SQL 直观，复杂的查询直接用 $queryRaw 反而更清晰，不要硬憋类型安全的写法。

5. schema 漂移

团队里有人绕过 migrate 手改了数据库，之后所有人 migrate dev 都会提示 drift。约定好：数据库结构变更只能通过 migration，谁都不许开例外。

总的来说 Prisma 依然是 Node 生态里开发体验最好的 ORM，只是它把复杂性藏到了你没注意到的地方。上面的坑踩过一遍之后，就又是稳稳的幸福了。