🚀 解决 Prisma 变慢问题

修复慢速 Prisma 查询
立即提速 2–7 倍（最高 53.5 倍）

Prisma 太慢？你并不孤单。喜欢 Prisma 的开发体验但需要更好的性能？ 将慢速 Prisma 查询速度提升 2–7 倍 （SQLite 关系过滤最高 53.5 倍），无需修改现有查询代码。

立即加速 Prisma 了解工作原理
更快的 Prisma 读取
无需改动查询
生产就绪
137 个端到端测试
一行代码解决 Prisma 慢 
import { PrismaClient, Prisma } from '@prisma/client'
import { speedExtension, convertDMMFToModels } from 'prisma-sql'
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL)
const models = convertDMMFToModels(Prisma.dmmf.datamodel)

const prisma = new PrismaClient().$extends(
  speedExtension({ postgres: sql, models })
)

const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true }
})
2–7倍
更快的 Prisma 读取
典型加速
0
查询改动
保持现有 Prisma 调用不变
137
端到端测试
已验证的解决方案
100%
类型安全
相同的 Prisma API

为什么 Prisma 慢？

了解 Prisma 的演进和性能特征有助于解释为什么存在这个扩展。

Prisma 的选择：优先 DX，但规模化时性能更关键

🎯 2019：现代 Prisma 的诞生

Prisma 2 于 2019 年推出，推动了 TypeScript ORM 的发展：基于 schema 的类型安全访问与类型生成。引擎式架构使 Prisma 能够翻译查询、验证输入并提供一致的 API 语义。

⚡ 2020–2022：快速增长与功能扩展

Prisma 增加了嵌套写入、事务与中间件等能力。功能更强的同时，每个查询仍要承担架构成本：请求表示、验证、执行与结果整形以匹配 Prisma API。

📊 2023：规模化时开销更明显

在高并发与读密集的生产负载中，固定的每次查询开销变得可测量。它通常在读取、分析、聚合以及大结果集上更明显。这不是 bug，而是 Prisma 保证与 API 行为的代价。

🚀 2024–2025：Prisma 持续优化性能

Prisma 在此期间发布了多次重要更新，包含性能与引擎层面的改进。即便如此，相比直接执行原始 SQL，查询处理与结果整形仍会带来不可避免的额外成本。

🎯 2026：prisma-sql 扩展发布

该扩展专注于读取性能。它为 findMany、findFirst、findUnique、count、aggregate、groupBy 提供更快的读取执行路径，同时保留 Prisma 用于写入、迁移、schema 管理与类型生成。上线前请确认与你的 Prisma 版本兼容。

💡 为什么存在这个扩展

Prisma 在类型安全、开发者体验与跨数据库一致性上做了正确的架构选择，但这些选择会带来规模化时明显的开销。此扩展不替代 Prisma，而是为读取提供更快的执行路径，保留 Prisma 的 DX。

查询转换层

Prisma 将查询输入转换为特定数据库的 SQL，从而实现一致的 API 行为与跨数据库语义，但在数据库执行前会增加处理时间。

验证与保证

Prisma 根据 schema 验证查询并确保 API 级别的保证。这些保障能避免一类问题，但也会增加每次查询的开销。

结果整形

结果会被整形以匹配 Prisma 的 API 行为。这提升了 DX 与一致性，但在大结果集与复杂 include 上会增加延迟。

此扩展通过为读取提供更快路径来补充 Prisma：保留 Prisma 的开发体验，同时在典型场景获得 2–7 倍更快的读取（SQLite 关系过滤最高 53.5 倍）。

到底快多少？真实基准测试

Prisma v6、v7、Drizzle ORM 与 Prisma-SQL 的全面对比

基准测试环境：MacBook Pro M1 • PostgreSQL 15 • SQLite 3.43 • 每个数据库 137 个测试用例

PostgreSQL

57 个测试用例的平均值

Prisma v6
2.10ms
Prisma v7
1.95ms
1.08× faster
Drizzle ORM
1.40ms
1.50× faster
Prisma-SQL ⚡
0.90ms
2.34× faster
6.3×
DISTINCT 查询
对比 Prisma v6
5.5×
关系过滤
对比 Prisma v6（"none"-过滤器）

SQLite

56 个测试用例的平均值

Prisma v6
5.48ms
Prisma v7
4.12ms
1.33× faster
Drizzle ORM
2.11ms
2.60× faster
Prisma-SQL ⚡
0.73ms
7.50× faster
12.6×
简单查询
对比 Prisma v6
69.7×
关系过滤
对比 Prisma v6（"none"-过滤器）

基准测试基于每个数据库 137 个 E2E 测试。Prisma v6.16.3, Prisma v7.2.0, Drizzle ORM latest. 查看完整基准测试数据 →

详细基准测试结果

采用 Welch t 检验并设置 1ms 实际显著性阈值的统计比较

这些结果反映了 运行时模式，在该模式下，每次请求都会将查询转换为 SQL。在 预渲染模式 中，SQL 在构建阶段生成——运行时直接执行原始的参数化查询，无任何转换开销。

PostgreSQL Prisma v6

平均 1.83x（相较于 Prisma） 平均 1.18x（相较于 Drizzle） 22/95 项具有统计显著性的胜出 73 项在噪声阈值范围内
Jul 19, 2026
测试 Prisma prisma-sql Drizzle 加速比 显著性 CV% n
findMany basic 0.506ms ±0.014 0.263ms ±0.045 0.328ms ~1.00x ≈ 61.8% 50
findMany where = 0.537ms ±0.031 0.520ms ±0.186 0.406ms ~1.00x ≈ 128.9% 50
findMany where >= 16.63ms ±0.392 5.04ms ±0.245 6.80ms 3.30x 1.35x D *** 17.5% 50
findMany where IN 0.643ms ±0.044 0.349ms ±0.024 0.423ms ~1.00x ≈ 24.3% 50
findMany where null 0.268ms ±0.0078 0.172ms ±0.0100 0.170ms ~1.00x ≈ 20.8% 50
findMany ILIKE 0.265ms ±0.0100 0.255ms ±0.0091 0.261ms ~1.00x ≈ 13.0% 50
findMany AND 2.77ms ±0.136 0.906ms ±0.078 1.60ms 3.06x 1.76x D *** 31.2% 50
findMany OR 14.41ms ±0.382 4.26ms ±0.294 5.31ms 3.38x 1.25x D *** 24.9% 50
findMany NOT 0.594ms ±0.015 0.383ms ±0.045 0.404ms ~1.00x ≈ 42.3% 50
findMany orderBy 1.71ms ±0.026 0.650ms ±0.068 0.567ms 2.63x 0.87x D *** 37.6% 50
findMany pagination 0.225ms ±0.029 0.148ms ±0.020 0.153ms ~1.00x ≈ 48.1% 50
findMany select 0.236ms ±0.0061 0.149ms ±0.026 0.104ms ~1.00x ≈ 61.8% 50
findMany relation some 0.880ms ±0.014 0.477ms ±0.039 — ~1.00x ≈ 29.2% 50
findMany relation every 0.689ms ±0.016 0.463ms ±0.022 — ~1.00x ≈ 17.4% 50
findMany relation none 30.27ms ±1.35 7.71ms ±0.265 — 3.93x *** 12.4% 50
findMany nested relation 0.732ms ±0.022 0.779ms ±0.085 — ~1.00x ≈ 39.5% 50
findMany complex 1.08ms ±0.018 0.448ms ±0.012 0.563ms ~1.00x ≈ 9.4% 50
findFirst 0.220ms ±0.018 0.196ms ±0.019 0.170ms ~1.00x ≈ 34.8% 50
findFirst skip 0.316ms ±0.033 0.188ms ±0.042 0.170ms ~1.00x ≈ 80.6% 50
findUnique id 0.181ms ±0.011 0.119ms ±0.0055 0.149ms ~1.00x ≈ 17.0% 50
findUnique email 0.185ms ±0.0089 0.114ms ±0.0053 0.137ms ~1.00x ≈ 16.7% 50
count 0.132ms ±0.017 0.062ms ±0.0022 0.083ms ~1.00x ≈ 12.9% 50
count where 0.468ms ±0.0089 0.282ms ±0.0047 0.285ms ~1.00x ≈ 6.1% 50
aggregate count 0.246ms ±0.0083 0.160ms ±0.0042 — ~1.00x ≈ 9.5% 50
aggregate sum/avg 0.341ms ±0.014 0.343ms ±0.033 — ~1.00x ≈ 34.6% 50
aggregate where 0.472ms ±0.020 0.289ms ±0.0069 — ~1.00x ≈ 8.7% 50
aggregate min/max 0.321ms ±0.0086 0.276ms ±0.0055 — ~1.00x ≈ 7.1% 50
aggregate complete 0.419ms ±0.011 0.341ms ±0.015 — ~1.00x ≈ 15.6% 50
groupBy 0.410ms ±0.0094 0.368ms ±0.0083 — ~1.00x ≈ 8.1% 50
groupBy count 0.457ms ±0.011 0.413ms ±0.048 — ~1.00x ≈ 41.7% 50
groupBy multi 0.576ms ±0.017 0.458ms ±0.011 — ~1.00x ≈ 8.7% 50
groupBy having 0.502ms ±0.014 0.470ms ±0.023 — ~1.00x ≈ 17.4% 50
groupBy + where 0.513ms ±0.0097 0.345ms ±0.040 — ~1.00x ≈ 41.6% 50
_count via include 0.668ms ±0.019 0.636ms ±0.015 — ~1.00x ≈ 8.6% 50
_count via include + relations 1.58ms ±0.040 1.36ms ±0.059 — ~1.00x ≈ 15.7% 50
groupBy aggregates 0.519ms ±0.021 0.435ms ±0.014 — ~1.00x ≈ 11.7% 50
groupBy min/max 0.495ms ±0.010 0.428ms ±0.013 — ~1.00x ≈ 10.8% 50
include list + nested to-one 1.45ms ±0.047 0.542ms ±0.112 — ~1.00x ≈ 74.4% 50
include list + nullable to-one 2.49ms ±0.044 1.47ms ±0.098 — 1.69x *** 24.0% 50
include posts 2.39ms ±0.026 1.95ms ±0.044 2.43ms ~1.00x ≈ 8.2% 50
include profile 0.480ms ±0.032 0.276ms ±0.010 0.405ms ~1.00x ≈ 13.3% 50
include 3 levels 1.66ms ±0.032 1.20ms ±0.017 1.94ms ~1.00x ≈ 5.1% 50
include 4 levels 1.82ms ±0.028 1.09ms ±0.045 1.43ms ~1.00x ≈ 14.8% 50
include + where 1.34ms ±0.095 0.720ms ±0.058 1.82ms ~1.00x ≈ 28.9% 50
include + select nested 1.20ms ±0.018 1.50ms ±0.027 1.66ms ~1.00x ≈ 6.5% 50
findMany startsWith 0.192ms ±0.017 0.296ms ±0.177 0.135ms ~1.00x ≈ 215.1% 50
findMany endsWith 0.535ms ±0.013 0.213ms ±0.041 0.273ms ~1.00x ≈ 69.4% 50
findMany NOT contains 0.591ms ±0.027 0.228ms ±0.037 0.269ms ~1.00x ≈ 59.3% 50
findMany LIKE 0.200ms ±0.0083 0.128ms ±0.017 0.150ms ~1.00x ≈ 47.3% 50
findMany < 27.75ms ±0.511 6.75ms ±0.182 10.01ms 4.11x 1.48x D *** 9.7% 50
findMany <= 28.51ms ±0.683 7.92ms ±0.560 11.99ms 3.60x 1.51x D *** 25.5% 50
findMany > 18.60ms ±2.68 4.32ms ±0.187 6.21ms 4.31x 1.44x D *** 15.7% 50
findMany NOT IN 0.635ms ±0.024 0.433ms ±0.146 0.663ms ~1.00x ≈ 121.7% 50
findMany isNot null 0.634ms ±0.026 0.279ms ±0.016 0.332ms ~1.00x ≈ 20.1% 50
orderBy multi-field 2.21ms ±0.072 0.862ms ±0.102 0.668ms 2.57x 0.78x D *** 42.6% 50
orderBy relation to-one 2.03ms ±0.054 1.42ms ±0.030 — ~1.00x ≈ 7.6% 50
orderBy relation + scalar 2.12ms ±0.030 1.45ms ±0.015 — ~1.00x ≈ 3.7% 50
orderBy nullable relation 2.22ms ±0.082 1.20ms ±0.053 — 1.85x *** 15.9% 50
orderBy deep relation 3.41ms ±0.076 1.95ms ±0.030 — 1.75x *** 5.6% 50
orderBy deep relation + scalar 3.33ms ±0.195 2.39ms ±0.067 — ~1.00x ≈ 10.1% 50
distinct status 8.60ms ±0.282 1.15ms ±0.026 — 7.49x *** 8.3% 50
distinct multi 12.81ms ±0.175 2.52ms ±0.036 — 5.07x *** 5.2% 50
cursor composite tuple 1.64ms ±0.021 1.27ms ±0.052 — ~1.00x ≈ 14.7% 50
cursor composite desc 1.85ms ±0.039 1.36ms ±0.015 — ~1.00x ≈ 4.0% 50
cursor prefix of orderBy 1.78ms ±0.029 1.29ms ±0.028 — ~1.00x ≈ 7.8% 50
select + include 0.971ms ±0.019 0.782ms ±0.071 0.309ms ~1.00x ≈ 32.8% 50
_count relation 0.752ms ±0.014 0.625ms ±0.020 — ~1.00x ≈ 11.5% 50
_count multi-relation 0.227ms ±0.030 0.154ms ±0.0053 — ~1.00x ≈ 12.2% 50
_count inside include 1.22ms ±0.030 1.05ms ±0.040 — ~1.00x ≈ 13.8% 50
_count inside nested select 1.77ms ±0.057 1.81ms ±0.137 — ~1.00x ≈ 27.2% 50
_count deep include 1.82ms ±0.025 1.36ms ±0.045 — ~1.00x ≈ 11.9% 50
ILIKE special chars 0.229ms ±0.014 0.157ms ±0.013 — ~1.00x ≈ 30.4% 50
LIKE case sensitive 0.205ms ±0.0091 0.130ms ±0.012 — ~1.00x ≈ 34.4% 50
findMany Date range 0.382ms ±0.040 0.470ms ±0.013 0.515ms ~1.00x ≈ 9.8% 50
count Date range 0.457ms ±0.011 0.374ms ±0.012 0.392ms ~1.00x ≈ 11.4% 50
findMany Date gte 0.331ms ±0.0091 0.147ms ±0.0039 0.182ms ~1.00x ≈ 9.6% 50
depth-1 low-fan 0.376ms ±0.016 0.229ms ±0.017 — ~1.00x ≈ 26.9% 50
depth-1 mid-fan 2.46ms ±0.032 2.01ms ±0.065 — ~1.00x ≈ 11.8% 50
depth-1 high-fan 2.17ms ±0.038 1.82ms ±0.029 — ~1.00x ≈ 5.8% 50
depth-1 wide 1.95ms ±0.029 1.37ms ±0.069 — ~1.00x ≈ 18.2% 50
depth-1 unbound 42.23ms ±0.621 10.82ms ±0.343 — 3.90x *** 11.4% 50
depth-2 3.77ms ±0.111 2.51ms ±0.222 — 1.50x *** 31.9% 50
depth-2 paginated Project→tasks 1.51ms ±0.112 1.83ms ±0.228 — ~1.00x ≈ 44.9% 50
depth-2 high-fan 2.09ms ±0.027 1.17ms ±0.079 — ~1.00x ≈ 24.3% 50
depth-2 wide 4.31ms ±0.162 1.29ms ±0.067 — 3.35x *** 18.8% 50
depth-2 unbound 63.87ms ±1.40 16.30ms ±0.669 — 3.92x *** 6.6% 10
depth-3 unbound 14.47ms ±0.261 5.95ms ±0.370 — 2.43x *** 22.5% 50
depth-3 paginated 1.64ms ±0.045 1.98ms ±0.236 — ~1.00x ≈ 43.1% 50
depth-4 unbound 8.78ms ±0.198 4.46ms ±0.197 — 1.97x *** 15.9% 50
depth-4 paginated 1.85ms ±0.072 1.60ms ±0.244 — ~1.00x ≈ 55.2% 50
findFirst depth-2 1.25ms ±0.028 0.991ms ±0.048 — ~1.00x ≈ 17.4% 50
findUnique depth-2 Project→tasks→comment 1.57ms ±0.065 0.962ms ±0.077 — ~1.00x ≈ 28.7% 50
complex nested select 2.90ms ±0.025 1.90ms ±0.112 — ~1.00x ≈ 21.3% 50
ultra deep query 13.63ms ±0.362 8.43ms ±0.169 — 1.62x *** 7.3% 50
transaction: (3 operations) 11.89ms ±0.190 9.51ms ±0.173 — 1.25x *** 6.6% 50
*** p < 0.001 ** p < 0.01 *  p < 0.05 ns 无统计显著性 ≈ 在 1ms 噪声阈值范围内 ± 95% 置信区间 CV% > 15% = 高方差
已对运行时模式进行基准测试。 预渲染模式在运行时完全跳过查询到 SQL 的转换——预计延迟将低于此处显示的结果，尤其是在复杂查询中，转换成本相对更高。
在 GitHub 上查看原始基准测试数据 →
✓ 已验证

我们如何确保正确性？

每个查询都通过 137 个端到端测试在 PostgreSQL 和 SQLite 上与 Prisma 进行验证

查看测试方法论 →

它如何优化 Prisma

绕过 Prisma 的读取执行路径，同时保留 Prisma 的 API 与类型

1

拦截 Prisma 查询

扩展在读取操作（findMany、findFirst、findUnique、count、aggregate、groupBy）执行前捕获它们

2

生成优化的 SQL

将 Prisma 查询转换为具有优化 JOIN 的快速参数化 SQL

3

直接执行

通过 postgres.js 或 better-sqlite3 直接执行读取，绕过 Prisma 读取开销

4

返回兼容结果

结果与 Prisma 期望的结构一致。类型、IntelliSense 与现有查询代码保持不变

const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true }
})

// 读取使用直接 SQL 执行
// 在该负载下基准约 ~1.00ms
// 查询代码不变
🔒 安全验证

我们如何防止 SQL 注入？

多层校验：参数绑定、基于 Schema 的字段检查与 137 个安全测试（当前套件）

查看安全详情 →

为什么选择这个 Prisma 扩展？

为读取获得更快的 SQL 执行速度，同时保留 Prisma 的开发体验

即时 Prisma 加速

一次性配置即可加速 Prisma 读取。无需重构、迁移或停机。

保留你的 Prisma 类型

保持完整的 TypeScript 支持。在加速读取的同时保留类型推断、自动完成与编译期安全性。

生产级验证方案

137 个端到端测试验证与较新 Prisma 版本兼容。已用于生产环境加速读取。

多数据库支持

在 PostgreSQL（包括 Neon、Supabase）与 SQLite 上优化 Prisma 读取。

预编译选项

可选生成器在构建时创建 SQL，将最热查询的开销减少到微秒。

Serverless 就绪（Node 运行时）

适用于 serverless Node 运行时。Edge 运行时支持取决于运行时限制与所使用的驱动。

Prisma 性能最重要的场景

此扩展产生实际影响的常见场景

📊 分析和报告

聚合与 groupBy 往往能从直接 SQL 执行中明显受益

  • groupBy 最高可加速约 5 倍
  • 更快的 aggregate 查询
  • 更低延迟的实时指标

🚀 高流量 API

在高并发下固定开销会叠加，尤其是读密集端点

  • 更低的 API 响应时间
  • 同等资源处理更多请求
  • 降低基础设施成本

☁️ 无服务器函数

无服务器中每毫秒都很重要：降低读取延迟

  • 更好的 p95/p99 读取延迟
  • 通过更快读取降低成本
  • 无需重构即可提速

📱 移动后端

用户能感知延迟：更快的读取能立即改善体验

  • 更快的信息流加载
  • 更快的分页
  • 更顺滑的交互

3 步优化 Prisma

在 60 秒内加速 Prisma 读取

① 安装 Prisma 扩展 

# PostgreSQL
npm install prisma-sql postgres

# SQLite
npm install prisma-sql better-sqlite3

② 将扩展添加到 Prisma Client 

import { PrismaClient, Prisma } from '@prisma/client'
import { speedExtension, convertDMMFToModels } from 'prisma-sql'
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL)
const models = convertDMMFToModels(Prisma.dmmf.datamodel)

const prisma = new PrismaClient().$extends(
  speedExtension({ postgres: sql, models })
)

③ 正常使用 Prisma 

const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true }
})

Prisma 性能常见问题

关于优化 Prisma 读取的常见问题

为什么 Prisma 有开销？

Prisma 会增加开销，因为它实现了 API 层保证：基于 schema 的验证、一致的查询行为和结果整形。这些层带来更好的开发体验，但相比直接执行原始 SQL 会消耗更多时间。

如何优化 Prisma 查询？

使用此扩展优化读密集场景。它通过 postgres.js 或 better-sqlite3 直接执行读取 SQL，同时保持 Prisma 的 API 与类型。只需要对 Prisma Client 初始化做一次小改动，无需重构现有查询。

Prisma 比原始 SQL 慢吗？

在很多读取负载下是的，因为存在架构性开销。此扩展的目标是在保留 Prisma DX 的同时，通过直接 SQL 执行降低读取延迟。

我可以在不修改现有查询的情况下加速 Prisma 吗？

可以。只需在 Prisma Client 初始化时加一次扩展，现有 Prisma 查询代码无需改变。读取会更快，同时 API、类型与 schema 保持一致。

这在生产中有效吗？

可以。它有 137 个端到端测试，并以生产使用为目标。上线前建议确认与你的 Prisma 版本兼容，并跑一遍自己的回归测试。

是什么导致 Prisma 聚合变慢？

聚合与 groupBy 往往会放大固定开销（查询处理与结果整形），并可能涉及更大的中间数据。此扩展通过直接生成并执行 SQL 来优化这些读取，通常能降低聚合型端点延迟。

准备好加速 Prisma 了吗？

加入已优化 Prisma 读取的开发者：提速 2–7 倍（最高 53.5 倍）

安装 Prisma-SQL 在 GitHub 上查看