Prisma查询远慢于MySQL原生查询，问题根源何在？

1. 对比Prisma生成SQL与原生SQL的差异 #

你的原生查询没有包含ORDER BY id DESC，但Prisma查询明确指定了orderBy: {id: 'desc'}，这是核心差异点：

• 当表中数据量较大时，排序操作会大幅增加查询耗时。
• 查看Prisma实际执行的SQL：在schema.prisma的datasource块中添加日志配置，运行项目后观察控制台输出的SQL是否有冗余操作，或排序逻辑是否可优化。

开启日志的schema配置示例：

datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
  log      = ["query"] // 添加该行开启查询日志
}

2. 验证索引的有效性 #

你的查询条件是location = ? AND status = 'RECEIVED'，同时需按id倒序排序：

• 原生查询可能利用了location或status的单字段索引，但Prisma的查询因排序逻辑可能选择了低效的执行计划。
• 建议创建联合索引覆盖查询+排序逻辑，避免额外排序开销，在MySQL中执行：

CREATE INDEX idx_documents_location_status_id ON tbl_documents (location, status, id DESC);

创建完成后重新运行Prisma查询，观察性能变化。

3. 排查Prisma连接池配置 #

Prisma默认连接池配置可能不匹配场景，导致每次查询重复建立连接（原生mysql模块可能复用了连接）：

• 在schema.prisma中调整连接池大小：

datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
  pool_size = 10 // 根据并发量调整，默认值为5
}

• 确保Prisma客户端是全局单例，避免每次请求新建实例：

// prisma/client.js
import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()

export default prisma

所有业务代码中导入该单例，而非每次创建新的PrismaClient实例。

4. 检查结果集大小与转换开销 #

若查询返回大量数据（数千条以上），Prisma将数据库行转换为JS对象的开销会比原生mysql模块更高。可先限制返回条数测试：

const documents = await prisma.tbl_documents.findMany({
  select: { barcode: true, name: true, description: true },
  where: { AND: [{ location: param.location }, { status: 'RECEIVED' }].filter(Boolean) },
  orderBy: { id: 'desc' },
  take: 100 // 先仅返回100条数据测试
});

若耗时明显下降，说明结果集过大是性能瓶颈之一，可改用分页查询优化。

内容的提问来源于stack exchange，提问作者Android_K.Doe