إصلاح استعلامات 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 },
})
SQL الذي ينفّذه prisma-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"]تعليمة واحدة
مخرجات createToSQL لمخطط من نموذجين، مع إضافة فواصل أسطر.
تغطية إصدارات Prisma
v6–v8
مصفوفة قياس أداء على PostgreSQL وSQLite
تغييرات على الاستعلامات
0
احتفظ باستدعاءات Prisma الحالية
ملفات القياس
6
Prisma v6/v7/v8 × PG/SQLite
أمان الأنواع
100%
نفس واجهة Prisma

لماذا Prisma بطيء؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تُكمل هذه الإضافة Prisma بتوفير مسار أسرع لاستعلامات القراءة المدعومة. تحتفظ بـPrisma للمخطط والترحيلات والكتابة والأنواع المولّدة، بينما يتولى 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): متوسط تسريع 1.99× مقارنةً بـ Prisma

    95 حالة استعلام مقيسة، المتوسط مقارنةً بـ Prisma30 سبتمبر 2026
  • Prisma v7 (7.10.0)1.51× مقارنةً بـ Drizzle
    1.47×

    Prisma v7 (7.10.0): متوسط تسريع 1.47× مقارنةً بـ Prisma

    95 حالة استعلام مقيسة، المتوسط مقارنةً بـ Prisma30 سبتمبر 2026
  • Prisma v8 (8.1.0-dev.1)1.63× مقارنةً بـ Drizzle
    1.54×

    Prisma v8 (8.1.0-dev.1): متوسط تسريع 1.54× مقارنةً بـ Prisma

    95 حالة استعلام مقيسة، المتوسط مقارنةً بـ Prisma30 سبتمبر 2026

SQLite

84 حالة استعلام لكل تشغيل
  • Prisma v6 (6.19.3)1.79× مقارنةً بـ Drizzle
    4.80×

    Prisma v6 (6.19.3): متوسط تسريع 4.80× مقارنةً بـ Prisma

    84 حالة استعلام مقيسة، المتوسط مقارنةً بـ Prisma30 سبتمبر 2026
  • Prisma v7 (7.10.0)1.84× مقارنةً بـ Drizzle
    2.29×

    Prisma v7 (7.10.0): متوسط تسريع 2.29× مقارنةً بـ Prisma

    84 حالة استعلام مقيسة، المتوسط مقارنةً بـ Prisma30 سبتمبر 2026
  • Prisma v8 (8.1.0-dev.1)1.63× مقارنةً بـ Drizzle
    2.10×

    Prisma v8 (8.1.0-dev.1): متوسط تسريع 2.10× مقارنةً بـ Prisma

    84 حالة استعلام مقيسة، المتوسط مقارنةً بـ Prisma30 سبتمبر 2026

مُولَّد وقت البناء من أحدث ملفات benchmark-results/*-latest.json. تتشارك الأشرطة مقياسًا واحدًا عبر قاعدتي البيانات؛ ويُميِّز اللون الكهرماني أفضل تشغيل لكل قاعدة بيانات. تتفاوت النتائج بين أشكال الاستعلامات الفردية.جدول لكل استعلامعرض بيانات القياس الكاملة

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

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

تعكس هذه النتائج وضع التشغيل، حيث تُحوَّل الاستعلامات إلى SQL عند كل طلب. في وضع المعالجة المسبقة، يُولَّد SQL وقت البناء — وينفّذ وقت التشغيل استعلامات خام ذات معاملات دون أي عبء تحويل.

PostgreSQLPrisma v6 (6.19.3)

المتوسط 1.99x مقارنةً بـ Prismaالمتوسط 1.56x مقارنةً بـ Drizzle35/95 تفوّق ذو دلالة إحصائية60 ضمن حد الضوضاء
30 سبتمبر 2026
الاختبار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 غير دال إحصائيًا≈ ضمن حد الضوضاء 1 مللي ثانية± فاصل الثقة 95%CV% > 15% = تباين مرتفع
تم قياس وضع التشغيل. وضع المعالجة المسبقة يتجاوز تحويل الاستعلام إلى SQL بالكامل أثناء التشغيل — توقّع زمن استجابة أقل مما هو معروض هنا، خاصةً للاستعلامات المعقدة حيث تكون كلفة التحويل أعلى نسبيًا.

المنهجية

  • –لإعادة الإنتاج: npm run bench (BENCHMARK_JSON_OUTPUT=1 يكتب JSON). تُحفظ النتائج في benchmark-results/summary-.json؛ ويغذّي v--latest.json هذه الصفحة.
  • –يعمل كل استعلام على قاعدة البيانات نفسها لجميع العملاء: Prisma وprisma-sql وDrizzle. يظهر حجم العينة لكل اختبار في العمود n.
  • –يُعرض لكل طرف: المتوسط والوسيط والانحراف المعياري (stdDev) وp95 وp99 وCV%. تعتمد الدلالة على اختبار t لـ Welch مع حد عملي قدره 1 مللي ثانية؛ وأشرطة الخطأ تمثل فاصل ثقة 95%.
  • –تم قياس وضع التشغيل: يُحوَّل SQL عند كل طلب. الاستعلامات المُعالجة مسبقًا (@optimize) تتجاوز التحويل بالكامل وهي أسرع مما هو معروض.
  • –يختلف العتاد والإصدارات بين التشغيلات - يحمل كل ملف JSON طابعه الزمني الخاص. قارن التشغيلات من الجهاز نفسه.

ما الذي يعمل أسرع، وما الذي يبقى في Prisma

كل ميزة في Prisma Client فحصناها، على PostgreSQL وSQLite. تبقى عمليات الكتابة في Prisma؛ وتُصرَّف عمليات القراءة إلى SQL حيث يكون شكل الاستعلام مدعومًا.

PostgreSQL
SQLite
دوال النموذجخيارات الاستعلامالمرشحاتالترتيبالتجميعاتواجهة العميلأنواع النتائج

25 من أصل 73 ميزة مفحوصة مُسرَّعة بالكامل على PostgreSQL. 19 قد تُرجع نتيجة مختلفة عن Prisma؛ وتسرد الخريطة الكاملة كلًّا منها مع السبب.

عدد الميزات حسب الحالة
الحالةPostgreSQLSQLite
مُسرَّع2521
جزئي66
يعود إلى Prisma97
يعمل في Prisma77
قد يختلف1917
غير متوفر24
prisma-sql فقط52
غير موجود في Prisma06
لم يُفحص03
افتح خريطة التكافؤ الكاملة
مُتحققكيف نضمن الصحة؟يتم التحقق من الاستعلامات المدعومة مقابل Prisma على PostgreSQL وSQLite، مع تقارير قياس أداء تغطي Prisma v6 وv7 وv8 وDrizzle وSQL المُولَّد.عرض منهجية الاختبار

كيف تُحسّن Prisma

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

  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 إلى SQL سريع ذي معاملات مربوطة مع JOINs مُحسّنة

    SQL لـ PostgreSQL
    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؟تحقق متعدد الطبقات مع ربط المعاملات وفحص الحقول المعتمد على المخطط ومجموعة اختبارات الأمان الحاليةعرض تفاصيل الأمان

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

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

تسريع فوري لـPrisma
إعداد لمرة واحدة يسرّع قراءات Prisma. بلا إعادة هيكلة، بلا ترحيل، بلا توقف.
احتفظ بأنواع Prisma
دعم TypeScript كامل. الاستدلال والتكملة التلقائية وأمان وقت الترجمة محفوظة مع تسريع القراءات.
حل مُختبر للإنتاج
تتحقق اختبارات التكافؤ الحالية من عمليات القراءة المدعومة عبر إصدارات Prisma الحديثة. استخدمه في تطبيقات الإنتاج بعد التحقق من التوافق مع إصدار Prisma وحمل العمل لديك.
دعم قواعد بيانات متعددة
حسّن قراءات Prisma على PostgreSQL (بما في ذلك Neon وSupabase) وSQLite.
خيار مُسبق التجميع
مولّد اختياري ينشئ SQL وقت البناء، ويقلل العبء إلى ميكروثوانٍ لأكثر استعلاماتك استخدامًا.
جاهز لـServerless (بيئات Node)
يعمل في بيئات Node من نوع Serverless. دعم بيئة 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. وقت التوليد يُجهَّز SQL الدقيق مسبقًا؛ والأشكال المطابقة وقت التشغيل تتجاوز التحويل بالكامل.

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

مخطِّط الكاردينالية

استراتيجية تختارها البيانات، لا التخمين

تقود إحصاءات العلاقات المجمَّعة التبديل بين الاستراتيجيات: الروابط المسطّحة (flat joins) والاستعلامات الفرعية المترابطة والتحميل المجزّأ عبر where-in. الجداول الفرعية الكبيرة لا تؤدي أبدًا إلى عمليات مسح لكل سجل أب.

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

متى يكون أداء Prisma أكثر أهمية

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

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

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

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

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

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

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

وظائف Serverless

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

  • p95/p99 أفضل للقراءات
  • تكلفة أقل عبر قراءات أسرع
  • قراءات أسرع بلا إعادة هيكلة

خوادم تطبيقات الجوال

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

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

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

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

  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 }) مع قاعدة بيانات better-sqlite3.دليل الإعداد الكامل

أسئلة شائعة حول أداء Prisma

أسئلة شائعة عن تحسين قراءات Prisma

لماذا لدى Prisma عبء إضافي؟

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

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

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

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

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

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

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

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

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

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

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

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

راجع جدول القياس الحالي لعمليات القراءة المدعومة في PostgreSQL وSQLite