🚀 الحل لمشكلة بطء Prisma

إصلاح استعلامات Prisma البطيئة
اجعل API أسرع 2–7× (حتى 53.5×)

هل Prisma بطيء؟ لست وحدك. تحب تجربة المطوّر في Prisma لكن تحتاج أداءً أفضل؟ سرّع استعلامات Prisma البطيئة بمقدار 2–7× (حتى 53.5× على مرشحات العلاقات في SQLite) بدون تغيير أي استعلامات موجودة.

سرّع Prisma الآن شاهد كيف يعمل
قراءات Prisma أسرع
بدون تغيير الاستعلامات
جاهز للإنتاج
137 اختبار E2E
إصلاح بطء 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
اختبار E2E
حل مُتحقق منه
100%
أمان الأنواع
نفس واجهة Prisma

لماذا Prisma بطيء؟

فهم تطور Prisma وخصائص الأداء يوضح لماذا توجد هذه الإضافة.

رحلة Prisma: DX أولًا، والأداء مهم عند التوسع

🎯 2019: ولادة Prisma الحديثة

أُطلق Prisma 2 في 2019 وغيّر مشهد ORM في TypeScript عبر وصول آمن بالأنواع لقاعدة البيانات وتوليد الأنواع من مخططك. قدّم Prisma بنية قائمة على محرك لترجمة الاستعلامات والتحقق منها وتقديم ضمانات كان من الصعب تحقيقها مع ORMs جافاسكربت التقليدية.

⚡ 2020–2022: نمو سريع وتوسّع الميزات

أضاف Prisma ميزات قوية مثل الكتابات المتداخلة والمعاملات وmiddleware. توسعت الميزات، لكن كل استعلام ظل يدفع كلفة معمارية: تمثيل الاستعلامات والتحقق منها وتنفيذها وتشكيل النتائج لتطابق واجهة Prisma.

📊 2023: يصبح العبء ملحوظًا عند التوسع

مع نشر المزيد من الفرق لـPrisma في أحمال عالية المرور، أصبح العبء الثابت لكل استعلام قابلًا للقياس. يظهر ذلك بوضوح في نقاط النهاية كثيفة القراءة والتحليلات والتجميعات ومجموعات النتائج الكبيرة. هذا العبء ليس خطأً؛ بل هو كلفة ضمانات Prisma وسلوك واجهته.

🚀 2024–2025: استمرار عمل Prisma على الأداء

أصدر Prisma تحديثات كبيرة تركز على الأداء وتغييرات المحرك. حتى مع التحسينات، تبقى هناك كلفة لا يمكن تجنبها لعمليات التحليل والتحقق والتخطيط وتشكيل النتائج مقارنة بتنفيذ SQL خام مباشرة.

🎯 2026: إصدار إضافة prisma-sql

تركّز هذه الإضافة على أداء القراءة. تتجاوز مسار تنفيذ القراءة في Prisma لعمليات findMany وfindFirst وfindUnique وcount وaggregate وgroupBy مع إبقاء Prisma للكتابة والترحيلات وإدارة المخطط وتوليد الأنواع. تحقّق من التوافق مع إصدار Prisma لديك قبل الإطلاق.

💡 لماذا توجد هذه الإضافة

اتخذ Prisma اختيارات معمارية مناسبة لأهدافه: أمان الأنواع وتجربة المطوّر وسلوك موحّد عبر قواعد البيانات. لكن هذه الاختيارات تولّد عبئًا ملحوظًا عند التوسع. هذه الإضافة لا تستبدل Prisma—بل تُحسّن القراءات للفرق التي تريد DX الخاص بـPrisma مع تنفيذ أسرع حيث يهم.

طبقة ترجمة الاستعلامات

يترجم Prisma مُدخلات الاستعلام إلى SQL خاص بقاعدة البيانات. يتيح ذلك سلوكًا موحّدًا عبر قواعد البيانات ودلالات واجهة Prisma، لكنه يضيف وقت معالجة قبل أن ترى قاعدة البيانات SQL.

التحقق وضمانات الأنواع

يُحقق Prisma الاستعلامات مقابل المخطط ويفرض ضمانات على مستوى الواجهة. تمنع هذه الضمانات فئات من الأخطاء لكنها تضيف عبئًا لكل استعلام.

تشكيل النتائج

تُشكّل النتائج لتطابق سلوك واجهة Prisma. هذا ممتاز لتجربة المطوّر والاتساق، لكنه يضيف زمنًا، خصوصًا مع مجموعات نتائج كبيرة وincludes معقدة.

تُكمل هذه الإضافة Prisma عبر توفير مسار أسرع لاستعلامات القراءة. تحتفظ بكل ما تحبه في Prisma مع الحصول على قراءات أسرع 2–7× عادةً (وحتى 53.5× على مرشحات العلاقات في SQLite) عندما تكون السرعة مهمة.

كم أسرع؟ معايير أداء حقيقية

مقارنة شاملة عبر 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. عرض بيانات القياس الكاملة →

نتائج القياس التفصيلية

مقارنة إحصائية باستخدام اختبار t لـ Welch وحد دلالة عملية قدره 1 مللي ثانية

تعكس هذه النتائج وضع التشغيل، حيث يتم تحويل الاستعلامات إلى 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 غير دال إحصائياً ≈ ضمن حد الضوضاء 1 مللي ثانية ± فاصل الثقة 95% CV% > 15% = تباين مرتفع
تم قياس وضع التشغيل. وضع المعالجة المسبقة يتجاوز تحويل الاستعلام إلى SQL بالكامل أثناء التشغيل — توقّع زمناً أقل للاستجابة مما هو معروض هنا، خاصةً للاستعلامات المعقدة حيث تكون تكلفة التحويل أعلى نسبياً.
عرض بيانات القياس الخام على GitHub →
✓ مُتحقق

كيف نضمن الصحة؟

يتم التحقق من كل استعلام مقابل Prisma عبر 137 اختبار end-to-end على PostgreSQL وSQLite

عرض منهجية الاختبار →

كيف تُحسّن Prisma

تجاوز مسار تنفيذ القراءة في Prisma مع الحفاظ على واجهة Prisma وأنواعها

1

اعتراض استعلامات Prisma

تلتقط الإضافة عمليات القراءة (findMany, findFirst, findUnique, count, aggregate, groupBy) قبل تنفيذها

2

توليد SQL مُحسّن

تحويل استعلامات Prisma إلى SQL سريع ومُعلّم بالمعاملات مع JOINs مُحسّنة

3

تنفيذ مباشر

تشغيل الاستعلامات عبر postgres.js أو better-sqlite3 مع تجاوز عبء قراءة Prisma

4

إرجاع نتائج متوافقة

تطابق النتائج الشكل المتوقع في Prisma. تبقى الأنواع وIntelliSense وكود الاستعلام كما هو

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

// Direct SQL execution for reads
// Benchmarked around ~1.00ms on this workload
// Same Prisma query code
🔒 آمن ومُتحقق

كيف نمنع حقن SQL؟

تحقق متعدد الطبقات مع ربط معاملات وفحص حقول معتمد على المخطط و137 اختبار أمان (المجموعة الحالية)

عرض تفاصيل الأمان →

لماذا تختار هذه الإضافة لـPrisma؟

احصل على سرعة SQL الخام للقراءات مع الحفاظ على تجربة Prisma للمطورين

تسريع فوري لـPrisma

إعداد لمرة واحدة يسرّع قراءات Prisma. بلا إعادة هيكلة، بلا ترحيل، بلا توقف.

احتفظ بأنواع Prisma

دعم TypeScript كامل. الاستدلال والتكملة التلقائية وأمان وقت الترجمة محفوظة مع تسريع القراءات.

حل مُختبر للإنتاج

137 اختبار E2E يتحقق من التوافق مع إصدارات Prisma الحديثة. يُستخدم لتسريع قراءات Prisma في تطبيقات إنتاجية.

دعم قواعد بيانات متعددة

حسّن قراءات Prisma على PostgreSQL (بما في ذلك Neon وSupabase) وSQLite.

خيار مُسبق التجميع

مولّد اختياري ينشئ SQL وقت البناء، ويقلل العبء إلى ميكروثوانٍ لأكثر استعلاماتك سخونة.

جاهز للسيرفرلس (بيئات Node)

يعمل في بيئات Node السيرفرلس. دعم Edge يعتمد على قيود البيئة والسائق الذي تستخدمه.

متى تهمّك أداء Prisma أكثر

سيناريوهات شائعة تُحدث فيها هذه الإضافة فرقًا حقيقيًا

📊 التحليلات والتقارير

تستفيد تجميعات Prisma وعمليات groupBy بشكل كبير من تنفيذ SQL مباشر

  • groupBy أسرع 5× يسرّع التقارير
  • استعلامات aggregate أسرع
  • مقاييس لحظية بزمن أقل

🚀 واجهات API عالية المرور

يتراكم العبء لكل استعلام تحت الحمل، خصوصًا لنقاط النهاية كثيفة القراءة

  • أزمنة استجابة أقل
  • معالجة طلبات أكثر لكل مثيل
  • خفض تكاليف البنية التحتية

☁️ وظائف Serverless

كل ميلي ثانية مهمة في السيرفرلس: قلّل زمن القراءة حيث يهم

  • p95/p99 أفضل للقراءات
  • تكلفة أقل عبر قراءات أسرع
  • قراءات أسرع بلا refactor

📱 Backends للموبايل

المستخدمون يلاحظون التأخير: القراءات الأسرع تحسن UX المُدرَك فورًا

  • تحميل feed أسرع
  • ترقيم صفحات أسرع
  • تفاعلات أكثر استجابة

حسّن Prisma في 3 خطوات

سرّع قراءات Prisma خلال أقل من 60 ثانية

① تثبيت إضافة 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 عبئًا لأنه يطبق ضمانات على مستوى الواجهة مثل التحقق المعتمد على المخطط والسلوك المتسق وتشكيل النتائج. هذه الطبقات تمنح تجربة مطوّر ممتازة لكنها تكلف وقتًا مقارنة بتنفيذ SQL خام مباشرة.

كيف أحسّن استعلامات Prisma؟

حسّن أحمال Prisma كثيفة القراءة بإضافة هذه الإضافة. تنفذ عمليات القراءة عبر SQL مباشر باستخدام postgres.js أو better-sqlite3 مع الحفاظ على واجهة Prisma وأنواعها. الإعداد تغيير صغير في التهيئة ولا يتطلب إعادة هيكلة لاستعلاماتك.

هل Prisma أبطأ من SQL الخام؟

بالنسبة للعديد من أحمال القراءة، نعم. هناك عبء معماري مقارنة بتنفيذ SQL الخام. تهدف هذه الإضافة إلى الحفاظ على DX الخاص بـPrisma مع تقليل زمن القراءة بتنفيذ SQL مباشرة.

هل يمكنني تسريع Prisma دون تغيير الاستعلامات الحالية؟

نعم. أضف الإضافة مرة واحدة أثناء تهيئة Prisma Client واحتفظ بكود استعلامات Prisma كما هو. ستصبح القراءات أسرع مع بقاء واجهة Prisma وأنواعها ومخططها نفسها.

هل يعمل ذلك في الإنتاج؟

نعم. تم التحقق منه عبر 137 اختبار E2E ومصمم للاستخدام في الإنتاج. تحقّق دائمًا من التوافق مع إصدار Prisma لديك وشغّل اختباراتك الرجعية قبل الإطلاق.

ما الذي يسبب بطء تجميعات Prisma؟

عمليات aggregate وgroupBy غالبًا تضخّم العبء الثابت (معالجة الاستعلام وتشكيل النتائج) وقد تشمل مجموعات وسيطة أكبر. تحسن هذه الإضافة هذه القراءات عبر توليد SQL مباشرة، ما يقلل عادةً زمن الاستجابة لنقاط النهاية كثيفة التجميع.

جاهز لتسريع Prisma؟

انضم إلى المطورين الذين يحسنون قراءات Prisma: أسرع 2–7× (حتى 53.5×)

تثبيت Prisma-SQL عرض على GitHub