Prisma执行Postgres findMany查询生产环境报P1001连接失败

P1001报错提示无法连接数据库，绝大多数场景下不是数据库服务真的宕机，而是查询性能过差触发连接超时、连接池被占满，Prisma客户端无法在超时窗口内拿到数据库响应才抛出的连接错误。本地环境数据量小查询返回快，所以不会触发问题，生产数据量级上来后，代码里的几个隐患会直接导致故障：

• 无限制全量拉取数据：当前findMany没有加任何条数限制，只要筛选命中的用户+关联Click数据量稍大，单次查询返回的结果集体积就会远超数据库连接的传输阈值，单个连接被长时间占用，超过超时阈值就会触发连接失败。
• 关联查询性能不足：include: {clicks: true}是一对多关联查询，命中用户数较多时，如果Click表关联User的外键字段没有加索引，关联阶段会产生大量全表扫描，查询耗时会指数级上升，直接打满数据库连接。
• 筛选条件未命中有效索引：当前用campaign in (...)+createdAt时间范围做筛选，两个字段如果没有建联合索引，数据库会全表扫描近50万条用户记录，筛选阶段就会消耗大量CPU、IO资源，进一步拉长查询时间。
• 额外性能损耗：把campaign的id和name都塞进同一个字段的in条件做匹配，当传入的campaign列表较长时，SQL解析、条件匹配的开销也会明显上升。

按优先级从高到低落地：

1. 禁止单次全量查询，必须分批拉取 #

不管是业务列表展示还是数据导出、统计场景，都不要一次把所有符合条件的数据拉回应用层：

• 如果是列表接口，直接做分页，单次返回条数控制在100条以内
• 如果是需要全量数据的场景，用游标分页分批拉取，性能远高于offset分页：

const BATCH_SIZE = 1000;
let allUsers = [];
let cursorId: number | null = null;

while (true) {
  const batch = await this.prisma.user.findMany({
    where: {
      campaign: {
        in: [
          ...campaigns.map((campaign) => campaign.id),
          ...campaigns.map((campaign) => campaign.name),
        ],
      },
      createdAt: {
        gte: dateRange.since,
        lt: dateRange.until,
      },
    },
    include: {
      clicks: true,
    },
    take: BATCH_SIZE,
    skip: cursorId ? 1 : 0,
    cursor: cursorId ? { id: cursorId } : undefined,
    orderBy: { id: 'asc' },
  });

  if (batch.length === 0) break;
  allUsers = allUsers.concat(batch);
  cursorId = batch[batch.length - 1].id;
}

• 如果是统计类需求，直接用Prisma的aggregate、groupBy语法在数据库层面完成计算，不要拉取原始明细到应用层处理。

2. 新增匹配的索引提升查询速度 #

在Prisma Schema中给对应字段加索引，遵循「等值查询字段在前，范围查询字段在后」的最左前缀匹配原则：

model User {
  // 其他已有字段
  id        Int      @id @default(autoincrement())
  campaign  String
  createdAt DateTime
  clicks    Click[]

  // 给筛选条件加联合索引
  @@index([campaign, createdAt])
}

model Click {
  // 其他已有字段
  id      Int  @id @default(autoincrement())
  userId  Int
  user    User @relation(fields: [userId], references: [id])

  // 给关联外键加索引，加速关联查询
  @@index([userId])
}

修改完Schema后，生产环境执行prisma migrate deploy同步索引到数据库即可。

3. 合理调整Prisma连接配置 #

在数据库连接串中调整连接池和超时参数，适配生产负载：

• connection_limit：连接池大小，单实例设置为CPU核心数*2即可，不要超过数据库配置的最大连接数，避免连接打满
• 适当调大超时阈值，避免大查询还未返回就被客户端主动断开
  示例连接串参数：

postgresql://用户名:密码@xyz:25060/库名?connection_limit=20&pool_timeout=30&connect_timeout=30&query_timeout=60

4. 优化campaign匹配逻辑 #

长期来看建议把campaign的id和name拆分为两个独立字段存储（比如campaignId、campaignName），分别做匹配，避免同一个字段同时存两种类型的值，既容易出现值冲突，也会增加查询开销。如果暂时无法改表，控制每次传入in条件的数组长度不超过100，参数过多时拆分为多次查询再合并结果。

如果调整后仍有问题，可以先去掉include: {clicks: true}配置，只查User表数据看是否能正常返回：

• 如果能正常返回，说明性能瓶颈在Click表的关联查询上，优先检查Click表的外键索引
• 如果仍然报错，打开数据库慢查询日志，查看这条SQL的执行耗时、扫描行数，同时监控数据库CPU、连接数使用率，执行查询时如果指标打满，即可确认是慢查询导致的连接异常，和网络连通性无关。

内容的提问来源于stack exchange，提问作者myoda999