修复慢速 Prisma 查询 直接执行 SQL

喜欢 Prisma 的开发体验，但希望在受支持的查询结构上降低读取开销？ 当前基准测试 JSON 显示了 Prisma v6、v7 和 v8 上的平均加速比 （受支持的 PostgreSQL 与 SQLite 读取）；各查询结构的结果不尽相同。

立即加速 Prisma

  • 更快的受支持读取
  • 无需改动查询
  • 当前基准测试 JSON
  • PostgreSQL 与 SQLite
你的 Prisma 调用user.findMany
const users = await prisma.user.findMany({
  where: { status: 'ACTIVE' },
  include: { posts: true },
})
prisma-sql 执行的 SQL
SELECT user_t.id, user_t.email, user_t.status,  COALESCE((    SELECT COALESCE(json_agg(json_build_object(      'id', posts_0.id,      'title', posts_0.title,      'authorId', posts_0."authorId"    )), '[]'::json)    FROM "public"."Post" posts_0    WHERE posts_0."authorId" = user_t.id  ), '[]'::json) AS postsFROM "public"."User" user_tWHERE user_t.status = $1
参数 ["ACTIVE"]1 条语句
createToSQL 针对两个模型的 schema 的输出，已添加换行。
Prisma 覆盖范围
v6–v8
PostgreSQL 与 SQLite 基准测试矩阵
查询改动
0
保持现有 Prisma 调用不变
基准测试文件
6
Prisma v6/v7/v8 × PG/SQLite
类型安全
100%
相同的 Prisma API

为什么 Prisma 慢？

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

Prisma 的历程：DX 优先，规模化时性能至关重要

💡 为什么存在这个扩展

Prisma 为其目标做出了正确的架构选择：类型安全、开发者体验和跨数据库行为。但这些选择会带来规模化时明显的开销。此扩展不替代 Prisma——它为希望兼得 Prisma DX 与关键路径上更快执行速度的团队优化读取。

  1. 🎯 2019：现代 Prisma 的诞生

    Prisma 2 于 2019 年发布，以类型安全的数据库访问和基于 schema 生成的类型改变了 TypeScript ORM 的格局。Prisma 引入了基于引擎的架构来翻译和验证查询，并提供传统 JavaScript ORM 难以实现的强保证。

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

    Prisma 增加了嵌套写入、事务和中间件等强大功能。功能集不断扩展，但每个查询仍要承担架构成本：查询需要被表示、验证、执行，结果还要整形以匹配 Prisma API。

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

    随着越来越多团队在高流量负载中部署 Prisma，固定的每次查询开销变得可测量。这在读密集型端点、分析、聚合和大结果集上最为明显。这种开销不是 bug，而是 Prisma 的保证与 API 行为的代价。

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

    Prisma 发布了专注于性能和引擎变更的重大更新。即使有这些改进，与直接执行原始 SQL 相比，解析、验证、规划和结果整形仍有不可避免的成本。

  5. 🎯 2026：prisma-sql 扩展发布

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

查询转换层

Prisma 将你的查询输入转换为特定数据库的 SQL。这实现了跨数据库行为和 Prisma 的 API 语义，但在数据库收到 SQL 之前增加了处理时间。

验证与类型保证

Prisma 根据 schema 验证查询并强制执行 API 级别的保证。这些保障能防止一类 bug，但也会增加每次查询的开销。

结果整形

结果会被整形以匹配 Prisma 的 API 行为。这有利于 DX 和一致性，但会增加延迟，尤其是在大结果集和复杂 include 上。

此扩展为受支持的读取查询提供更快的路径，作为 Prisma 的补充。你继续使用 Prisma 管理 schema、迁移、写入和生成的类型，而生成的 SQL 通过数据库原生客户端处理选定的热点读取。

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

基于最新基准测试 JSON，对比 Prisma v6、v7、v8、Drizzle ORM 与 prisma-sql

PostgreSQL

每次运行 95 个查询用例
  • Prisma v6 (6.19.3)1.56×（相较于 Drizzle）
    1.99×

    Prisma v6 (6.19.3)：相较于 Prisma 平均加速 1.99×

    95 个已测量的查询用例，相较于 Prisma 的平均值2026年9月30日
  • Prisma v7 (7.10.0)1.51×（相较于 Drizzle）
    1.47×

    Prisma v7 (7.10.0)：相较于 Prisma 平均加速 1.47×

    95 个已测量的查询用例，相较于 Prisma 的平均值2026年9月30日
  • Prisma v8 (8.1.0-dev.1)1.63×（相较于 Drizzle）
    1.54×

    Prisma v8 (8.1.0-dev.1)：相较于 Prisma 平均加速 1.54×

    95 个已测量的查询用例，相较于 Prisma 的平均值2026年9月30日

SQLite

每次运行 84 个查询用例
  • Prisma v6 (6.19.3)1.79×（相较于 Drizzle）
    4.80×

    Prisma v6 (6.19.3)：相较于 Prisma 平均加速 4.80×

    84 个已测量的查询用例，相较于 Prisma 的平均值2026年9月30日
  • Prisma v7 (7.10.0)1.84×（相较于 Drizzle）
    2.29×

    Prisma v7 (7.10.0)：相较于 Prisma 平均加速 2.29×

    84 个已测量的查询用例，相较于 Prisma 的平均值2026年9月30日
  • Prisma v8 (8.1.0-dev.1)1.63×（相较于 Drizzle）
    2.10×

    Prisma v8 (8.1.0-dev.1)：相较于 Prisma 平均加速 2.10×

    84 个已测量的查询用例，相较于 Prisma 的平均值2026年9月30日

在构建时根据最新的 benchmark-results/*-latest.json 文件生成。两个数据库的柱状图使用同一刻度；琥珀色标记每个数据库的最佳运行。各查询结构的结果不尽相同。逐查询表格查看完整基准测试数据

详细基准测试结果

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

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

PostgreSQLPrisma v6 (6.19.3)

平均 1.99x（相较于 Prisma）平均 1.56x（相较于 Drizzle）35/95 项具有统计显著性的胜出60 项在噪声阈值范围内
2026年9月30日
测试Prismaprisma-sqlDrizzle加速比显著性CV%n
findMany basic0.529ms±0.0640.231ms±0.2340.271ms~1.00x≈198.0%50
findMany where =0.501ms±0.00690.208ms±0.00940.347ms~1.00x≈15.6%50
findMany where >=16.51ms±0.2675.67ms±0.3387.43ms2.91x1.31x D***21.0%50
findMany where IN0.657ms±0.1420.292ms±0.0170.492ms~1.00x≈20.3%50
findMany where null0.280ms±0.0200.167ms±0.0120.177ms~1.00x≈25.7%50
findMany ILIKE0.297ms±0.00970.168ms±0.00890.278ms~1.00x≈18.6%50
findMany AND2.72ms±0.1611.11ms±0.1111.45ms2.45x1.31x D***31.5%50
findMany OR13.98ms±0.2864.69ms±0.2215.88ms2.98x1.25x D***17.0%50
findMany NOT0.639ms±0.0130.274ms±0.00910.478ms~1.00x≈12.2%50
findMany orderBy4.50ms±0.2191.48ms±0.0751.76ms3.03x1.18x D***18.5%50
findMany pagination0.342ms±0.0320.171ms±0.0260.295ms~1.00x≈43.2%50
findMany select0.294ms±0.00940.181ms±0.00720.176ms~1.00x≈14.0%50
findMany relation some1.69ms±0.0980.999ms±0.064—~1.00x≈22.1%50
findMany relation every2.17ms±0.0961.47ms±0.078—~1.00x≈18.9%50
findMany relation none26.02ms±0.51710.06ms±0.511—2.59x***18.0%50
findMany nested relation1.76ms±0.0761.24ms±0.060—~1.00x≈18.0%50
findMany complex2.94ms±0.1091.46ms±0.0681.73ms2.01x1.18x D***17.2%50
findFirst0.378ms±0.0320.175ms±0.0140.350ms~1.00x≈28.0%50
findFirst skip0.328ms±0.1070.147ms±0.00640.301ms~1.00x≈15.2%50
findUnique id0.232ms±0.00970.102ms±0.00550.207ms~1.00x≈18.6%50
findUnique email0.210ms±0.00720.090ms±0.00440.179ms~1.00x≈17.1%50
count0.109ms±0.00330.063ms±0.00300.064ms~1.00x≈16.2%50
count where0.469ms±0.0150.247ms±0.0160.287ms~1.00x≈22.2%50
aggregate count0.215ms±0.00780.155ms±0.0042—~1.00x≈9.2%50
aggregate sum/avg0.305ms±0.0140.261ms±0.0053—~1.00x≈7.1%50
aggregate where0.446ms±0.01000.239ms±0.0058—~1.00x≈8.7%50
aggregate min/max0.305ms±0.0150.268ms±0.010—~1.00x≈13.2%50
aggregate complete0.381ms±0.00610.292ms±0.0072—~1.00x≈8.8%50
groupBy0.419ms±0.0240.344ms±0.013—~1.00x≈12.8%50
groupBy count0.422ms±0.01000.358ms±0.0050—~1.00x≈4.8%50
groupBy multi0.544ms±0.0130.442ms±0.052—~1.00x≈38.9%50
groupBy having0.505ms±0.0110.375ms±0.0086—~1.00x≈8.2%50
groupBy + where0.550ms±0.0110.294ms±0.0064—~1.00x≈7.8%50
_count via include0.679ms±0.0130.511ms±0.013—~1.00x≈8.9%50
_count via include + relations1.55ms±0.0370.666ms±0.017—~1.00x≈9.3%50
groupBy aggregates0.557ms±0.00970.465ms±0.0091—~1.00x≈6.9%50
groupBy min/max0.531ms±0.00800.441ms±0.0053—~1.00x≈4.2%50
include list + nested to-one1.46ms±0.0290.337ms±0.032—4.32x***30.2%50
include list + nullable to-one2.59ms±0.0811.65ms±0.056—~1.00x≈11.9%50
include posts4.25ms±0.2162.35ms±0.1205.77ms1.81x2.45x D***18.9%50
include profile0.635ms±0.8710.540ms±0.2410.648ms~1.00x≈104.7%50
include 3 levels4.48ms±0.1484.03ms±0.1474.58ms~1.00x≈13.6%50
include 4 levels5.61ms±0.1823.39ms±0.1324.65ms1.65x1.37x D***13.9%50
include + where4.04ms±0.1762.88ms±0.3995.51ms~1.00x≈46.7%50
include + select nested2.52ms±0.1391.96ms±0.1854.42ms~1.00x≈31.8%50
findMany startsWith0.270ms±0.0280.140ms±0.0140.314ms~1.00x≈35.4%50
findMany endsWith0.563ms±0.0150.216ms±0.00690.369ms~1.00x≈11.1%50
findMany NOT contains0.627ms±0.0220.250ms±0.1040.447ms~1.00x≈121.8%50
findMany LIKE0.245ms±0.00940.111ms±0.00690.250ms~1.00x≈21.9%50
findMany <25.55ms±0.3987.55ms±0.29210.60ms3.39x1.40x D***13.4%50
findMany <=26.43ms±0.3717.78ms±0.22010.97ms3.40x1.41x D***10.2%50
findMany >15.55ms±0.5995.21ms±0.3566.78ms2.99x1.30x D***24.2%50
findMany NOT IN0.644ms±0.0130.282ms±0.0110.487ms~1.00x≈13.4%50
findMany isNot null0.642ms±0.0140.336ms±0.0170.362ms~1.00x≈18.6%50
orderBy multi-field4.99ms±0.1901.55ms±0.0761.88ms3.22x1.21x D***17.0%50
orderBy relation to-one4.10ms±0.1353.08ms±0.090—1.33x***10.2%50
orderBy relation + scalar5.02ms±0.2583.63ms±0.205—1.39x***20.0%50
orderBy nullable relation4.08ms±0.3002.94ms±0.181—1.39x***21.1%50
orderBy deep relation5.43ms±0.1864.04ms±0.174—1.34x***14.9%50
orderBy deep relation + scalar6.34ms±0.1354.62ms±0.100—1.37x***7.8%50
distinct status8.84ms±0.3761.56ms±0.181—5.66x***36.9%50
distinct multi12.04ms±0.1712.50ms±0.073—4.81x***10.3%50
cursor composite tuple1.61ms±0.0251.13ms±0.017—~1.00x≈5.3%50
cursor composite desc1.75ms±0.0371.31ms±0.021—~1.00x≈5.8%50
cursor prefix of orderBy2.70ms±0.1881.66ms±0.082—1.63x***18.1%50
select + include1.60ms±0.1010.309ms±0.0210.568ms5.16x1.84x D***24.6%50
_count relation1.74ms±0.3411.67ms±0.781—~1.00x≈123.8%50
_count multi-relation0.257ms±0.0290.218ms±0.045—~1.00x≈62.4%50
_count inside include2.32ms±0.1261.55ms±0.124—~1.00x≈32.0%50
_count inside nested select4.64ms±0.2023.69ms±0.266—~1.00x≈24.3%50
_count deep include5.49ms±0.2473.98ms±0.158—1.38x***14.1%50
ILIKE special chars0.425ms±0.0330.193ms±0.022—~1.00x≈36.5%50
LIKE case sensitive0.263ms±0.0100.110ms±0.0078—~1.00x≈24.0%50
findMany Date range0.424ms±0.0120.190ms±0.0120.321ms~1.00x≈21.1%50
count Date range1.14ms±0.0470.925ms±0.0520.995ms~1.00x≈19.8%50
findMany Date gte0.403ms±0.0250.178ms±0.00580.303ms~1.00x≈11.6%50
depth-1 low-fan0.566ms±0.0210.447ms±0.102—~1.00x≈73.7%50
depth-1 mid-fan4.21ms±0.1102.34ms±0.178—1.80x***26.3%50
depth-1 high-fan4.16ms±0.1222.25ms±0.130—1.85x***20.4%50
depth-1 wide3.11ms±0.1141.78ms±0.166—1.75x***31.3%50
depth-1 unbound39.65ms±3.789.43ms±0.884—4.21x***29.1%50
depth-24.78ms±0.1533.54ms±0.187—1.35x***18.6%50
depth-2 paginated Project→tasks3.16ms±0.1492.68ms±0.161—~1.00x≈20.6%50
depth-2 high-fan3.84ms±0.1852.86ms±0.229—~1.00x≈28.7%50
depth-2 wide4.90ms±0.1763.08ms±0.176—1.59x***20.6%50
depth-2 unbound65.60ms±1.5217.60ms±0.479—3.73x***4.4%10
depth-3 unbound15.32ms±0.2818.38ms±0.354—1.83x***15.8%50
depth-3 paginated2.44ms±0.1562.34ms±0.253—~1.00x≈32.7%50
depth-4 unbound9.96ms±0.2686.14ms±0.266—1.62x***15.7%50
depth-4 paginated3.42ms±0.1612.42ms±0.175—~1.00x≈23.6%50
findFirst depth-22.91ms±0.1142.30ms±0.173—~1.00x≈25.9%50
findUnique depth-2 Project→tasks→comment3.27ms±0.1132.16ms±0.173—1.52x***27.5%50
complex nested select4.51ms±0.4283.01ms±0.777—~1.00x≈65.7%50
ultra deep query15.94ms±0.5465.83ms±0.361—2.73x***22.0%50
transaction: (3 operations)3.00ms±0.2751.41ms±0.246—2.14x***53.2%50
*** p < 0.001** p < 0.01*  p < 0.05ns 无统计显著性≈ 在 1ms 噪声阈值范围内± 95% 置信区间CV% > 15% = 高方差
已对运行时模式进行基准测试。 预渲染模式在运行时完全跳过查询到 SQL 的转换——预计延迟将低于此处显示的结果，尤其是在复杂查询中，转换成本相对更高。
在 GitHub 上查看原始基准测试数据 →

方法论

  • –复现方式：npm run bench（BENCHMARK_JSON_OUTPUT=1 会写出 JSON）。结果保存在 benchmark-results/summary-.json；本页面数据来自 v--latest.json。
  • –所有客户端（Prisma、prisma-sql、Drizzle）的每个查询都针对同一个数据库运行。每个测试的样本量显示在 n 列中。
  • –每一方报告：平均值、中位数、标准差、p95、p99、CV%。显著性采用 Welch t 检验并设置 1ms 实际阈值；误差线为 95% 置信区间。
  • –测量的是运行时模式：每次请求都会转换 SQL。预渲染（@optimize）查询完全跳过转换，速度比此处显示的更快。
  • –不同运行之间的硬件和版本各不相同——每个 JSON 文件都带有自己的时间戳。请比较同一台机器上的运行结果。

哪些运行更快，哪些仍由 Prisma 执行

我们检查过的每个 Prisma Client 功能，覆盖 PostgreSQL 和 SQLite。写入仍由 Prisma 执行；在查询结构受支持时，读取会被编译为 SQL。

PostgreSQL
SQLite
模型方法查询选项过滤器排序聚合客户端 API结果类型

在已检查的 73 个功能中，有 25 个在 PostgreSQL 上完全加速。19 个可能返回与 Prisma 不同的结果；完整对照表列出了每一项及其原因。

按状态统计的功能数量
状态PostgreSQLSQLite
已加速2521
部分加速66
回退97
由 Prisma 执行77
可能不同1917
不可用24
仅 prisma-sql52
Prisma 不支持06
未检查03
打开完整的对等性对照表
已验证我们如何确保正确性？受支持的查询在 PostgreSQL 和 SQLite 上与 Prisma 进行对照验证，基准测试报告覆盖 Prisma v6、v7、v8、Drizzle 和生成的 SQL。查看测试方法论

它如何优化 Prisma

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

  1. 拦截 Prisma 查询

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

    generated/sql，节选
    query: {
  $allModels: {
    async $allOperations({ model, operation, args, query }) {
      if (!ACCELERATED_METHODS.has(operation)) {
        return query(args)
      }
      return executeAccelerated(model, operation, args, query)
    },
  },
}

  2. 生成优化的 SQL

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

    PostgreSQL 的 SQL
    SELECT user_t.id, user_t.email, user_t.status,
  COALESCE((
    SELECT COALESCE(json_agg(json_build_object(
      'id', posts_0.id,
      'title', posts_0.title,
      'authorId', posts_0."authorId"
    )), '[]'::json)
    FROM "public"."Post" posts_0
    WHERE posts_0."authorId" = user_t.id
  ), '[]'::json) AS posts
FROM "public"."User" user_t
WHERE user_t.status = $1

-- params ["ACTIVE"]

  3. 直接执行

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

    generated/sql，节选
    if (DIALECT === 'postgres') {
  await client.unsafe(sql, normalizedParams).forEach((row) => {
    results.push(row)
  })
  return results
}

const stmt = getOrPrepareStatement(client, sql)
return stmt.all(...normalizedParams)

  4. 返回兼容结果

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

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

users[0].email
users[0].posts[0].title

// 与 Prisma Client 推断的类型相同。
// Decimal、BigInt 和 DateTime 值可能
// 不同；对等性对照表列出了每种情况。
安全验证我们如何防止 SQL 注入？多层校验：参数绑定、基于 schema 的字段检查，以及当前的安全测试套件查看安全详情

为什么选择这个 Prisma 扩展？

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

即时 Prisma 加速
一次性配置即可加速 Prisma 读取。无需重构、迁移或停机。
保留你的 Prisma 类型
保持完整的 TypeScript 支持。在加速读取的同时保留类型推断、自动完成与编译期安全性。
经过生产测试的方案
当前的对等性测试在近期的 Prisma 版本上验证受支持的读取。在确认与你的 Prisma 版本和负载兼容后，可用于生产应用。
多数据库支持
在 PostgreSQL（包括 Neon、Supabase）与 SQLite 上优化 Prisma 读取。
预编译选项
可选生成器在构建时创建 SQL，将最热查询的开销减少到微秒级。
Serverless 就绪（Node 运行时）
适用于 serverless Node 运行时。Edge 运行时支持取决于运行时限制与所使用的驱动。

不止于更快的读取

prisma-sql 增加了 Prisma Client 所没有的能力。相同的类型，相同的代码风格。

$batch

N 个仪表盘查询，一次往返

将独立的读取合并为一次 PostgreSQL 往返。返回带类型的对象结果，无需手动处理 Promise.all。

const dash = await prisma.$batch((b) => ({
  users: b.user.count(),
  posts: b.post.findMany({ take: 10 }),
  stats: b.task.aggregate({ _count: true }),
}))

@optimize

预先生成最热查询

在 schema.prisma 中为模型添加注解。在 generate 时生成确切的 SQL；运行时匹配的查询结构完全跳过转换。

/// @optimize {
///   "method": "findMany",
///   "query": {
///     "where": { "status": "$status" },
///     "take": "$take"
///   }
/// }
model User { ... }

基数规划器

策略由数据决定，而非猜测

收集的关系统计信息驱动策略在扁平 JOIN、关联子查询和 where-in 分段加载之间切换。大型子表永远不会触发逐父记录扫描。

prisma-sql-collect-stats \
  --output dist/planner.generated.js \
  --prisma-client dist/client/index.js

Prisma 性能最重要的场景

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

分析和报告

Prisma 的聚合和 groupBy 操作能从直接 SQL 执行中显著受益

  • groupBy 快 5 倍，报表生成更快
  • 更快的聚合查询
  • 更低延迟的实时指标

高流量 API

每次查询的开销在负载下不断累积，尤其是在读密集型端点上

  • 更低的 API 响应时间
  • 每个实例处理更多请求
  • 降低基础设施成本

无服务器函数

在无服务器环境中每一毫秒都很重要：在关键处降低读取延迟

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

移动后端

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

  • 更快的信息流加载
  • 更快的分页
  • 响应更灵敏的交互

3 步优化 Prisma

在 60 秒内加速 Prisma 读取

  1. 安装 Prisma 扩展

    Terminal
    # PostgreSQL
npm install prisma-sql postgres

# SQLite
npm install prisma-sql better-sqlite3

  2. 将扩展添加到 Prisma Client

    schema.prisma
    generator client {
  provider = "prisma-client"
}

generator sql {
  provider = "prisma-sql-generator"
}
    Terminal
    npx prisma generate
    db.ts
    import { PrismaClient } from '@prisma/client'
import { speedExtension, type SpeedClient } from './generated/sql'
import postgres from 'postgres'

const sql = postgres(process.env.DATABASE_URL!)
const basePrisma = new PrismaClient()

export const prisma = basePrisma.$extends(
  speedExtension({ postgres: sql }),
) as SpeedClient<typeof basePrisma>

  3. 正常使用 Prisma

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

SQLite：传入 speedExtension({ sqlite: db })，其中 db 为 better-sqlite3 数据库。完整安装指南

Prisma 性能常见问题

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

为什么 Prisma 有开销？

Prisma 之所以有开销，是因为它实现了 API 保证，例如基于 schema 的验证、一致的查询行为和结果整形。这些层带来出色的开发体验，但与直接执行原始 SQL 相比会耗费时间。

如何优化 Prisma 查询？

为读密集型 Prisma 负载添加此扩展即可优化。它通过 postgres.js 或 better-sqlite3 以直接 SQL 执行读取操作，同时保留 Prisma 的 API 与类型。设置只需对初始化做一次小改动，无需重构现有查询。

Prisma 比原始 SQL 慢吗？

对于许多读取负载来说，是的。与原始 SQL 执行相比存在架构性开销。此扩展旨在保留 Prisma DX 的同时，通过直接执行 SQL 降低读取延迟。

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

可以。在 Prisma Client 初始化时添加一次扩展，现有 Prisma 查询代码保持不变。读取操作运行得更快，而 Prisma API、类型与 schema 保持不变。

这能用于生产环境吗？

可以，它面向受支持读取路径上的生产使用而设计。上线前务必验证与你的 Prisma 版本的兼容性，并运行你自己的回归测试。

是什么导致 Prisma 聚合变慢？

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

准备好加速 Prisma 了吗？

查看当前基准测试表中受支持的 PostgreSQL 与 SQLite 读取结果

安装 Prisma-SQL在 GitHub 上查看