المهارات supabase-postgres-best-practices
🐘

supabase-postgres-best-practices

آمن ⚡ يحتوي على سكربتات⚙️ الأوامر الخارجية🌐 الوصول إلى الشبكة

تحسين أداء Postgres باستخدام أفضل الممارسات الخبيرة

متاح أيضًا من: supabase

تعاني تطبيقات Postgres من الاستعلامات البطيئة وتصميم المخطط الضعيف. توفر هذه المهارة 26 قاعدة ذات أولوية من خبراء Supabase لتحقيق تحسينات في الأداء تصل إلى 10-1000 مرة.

يدعم: Claude Codex Code(CC)
🥉 73 برونزي
1

تنزيل ZIP المهارة

2

رفع في Claude

اذهب إلى Settings → Capabilities → Skills → Upload skill

3

فعّل وابدأ الاستخدام

اختبرها

استخدام "supabase-postgres-best-practices". راجع استعلام Postgres الخاص بي واقترح تحسينات بناءً على أفضل الممارسات: SELECT * FROM events WHERE user_id = 123 ORDER BY created_at DESC LIMIT 20

النتيجة المتوقعة:

بناءً على قواعد query-missing-indexes.md، يحتاج استعلامك إلى فهرس على أعمدة التصفية والترتيب:

1. أضف فهرساً مركباً:
```sql
CREATE INDEX events_user_id_created_at_idx
ON events (user_id, created_at DESC);
```

2. التحسين المتوقع: يقلل فحص الفهرس التكلفة من 25000 إلى 8.44 (أسرع بـ 100-1000 مرة على الجداول الكبيرة).

3. لاستعلامات LIMIT، فكر في استخدام فهارس التغطية لتجنب عمليات البحث في الجدول إذا كنت تحتاج فقط أعمدة محددة.

استخدام "supabase-postgres-best-practices". هل يتبع نمط الإدراج المجمع أفضل الممارسات؟ for (let i = 0; i < 1000; i++) { await db.query('INSERT INTO logs (message) VALUES ($1)', [logs[i]]); }

النتيجة المتوقعة:

لا، هذا ينتهك قواعد data-batch-inserts.md. ��ديك:

- 1000 رحلة ذهاب وعودة فردية
- 1000 معاملة منفصلة
- أبطأ 10-50 مرة من اللازم

النهج الصحيح (من القواعد):
```sql
INSERT INTO logs (message) VALUES
($1), ($2), ($3), ... حتى ~1000 صف;
```

أو استخدم COPY للاستيراد الضخم (أسرع طريقة). راجع data-batch-inserts.md للأمثلة.

استخدام "supabase-postgres-best-practices". هل يجب أن أضيف فهرساً على عمود المفتاح الأجنبي هذا الذي يتم الاستعلام عنه أحياناً؟

النتيجة المتوقعة:

نعم، بالتأكيد. من schema-foreign-key-indexes.md:

**التأثير: حرج (تحسين 5-20 مرة)**

يجب فهرسة أعمدة المفاتيح الأج��بية دائماً تقريباً لأن:
1. JOINs على المفاتيح الأجنبية تسبب فحوصات متسلسلة بدون فهارس
2. عمليات DELETE على الجداول الأم تتطلب فحص الجداول الفرعية
3. تصبح العمليات المتتالية أبطأ بشكل أسي على الجداول الكبيرة

تلاحظ القاعدة: الاستعلامات العرضية تستفيد من فهرسة المفاتيح الأجنبية بسبب تكاليف الفحص الأسي.

التدقيق الأمني

آمن
v1 • 2/25/2026

All 710 static findings are false positives. This is a documentation-only skill containing Postgres best practices in Markdown format. The flagged patterns (backticks, MD5 references, URLs, system queries) are all legitimate SQL examples, documentation links, and monitoring queries. No executable code, no data exfiltration, no malicious intent detected.

37
الملفات التي تم فحصها
3,485
الأسطر التي تم تحليلها
8
النتائج
1
إجمالي عمليات التدقيق
مشكلات متوسطة المخاطر (1)
False Positive - SQL Code Blocks Flagged as External Commands
Static scanner detected 344 instances of 'Ruby/shell backtick execution' across Markdown files. Investigation confirms these are Markdown code blocks containing SQL examples (e.g., ```sql ... ```) and inline backticks for emphasis. No actual shell execution exists. Confidence: 0.98 - Direct evidence that backticks are Markdown syntax, not executable code.
مشكلات منخفضة المخاطر (4)
False Positive - MD5 References Not Cryptographic Weakness
Static scanner flagged 46 instances of 'Weak cryptographic algorithm (MD5)'. Investigation confirms these are: (1) MD5 checksums in documentation URLs (Supabase/PostgreSQL docs), (2) File integrity hashes in metadata.json, not actual cryptographic implementations. No security risk. Confidence: 0.95 - Clear evidence these are documentation references, not crypto code.
False Positive - Hardcoded URLs Are Legitimate Documentation Links
Static scanner detected 72 'Hardcoded URL' instances. Investigation confirms all are legitimate documentation references to supabase.com/docs and postgresql.org/docs. No external data exfiltration, no malicious endpoints. Confidence: 0.99 - All URLs point to official Supabase/PostgreSQL documentation.
False Positive - System Queries Are Legitimate Monitoring
Static scanner flagged 158 'System reconnaissance' patterns. Investigation confirms these are standard PostgreSQL monitoring queries (pg_stat_activity, pg_class, pg_indexes) used for performance diagnostics. No reconnaissance activity. Confidence: 0.97 - Standard Postgres system catalog queries for DBA monitoring.
False Positive - SQL WITH Clauses Not JavaScript with Statements
Static scanner detected 4 'with statement (deprecated)' patterns. Investigation confirms these are SQL Common Table Expressions (CTEs) using 'WITH' clause, not deprecated JavaScript 'with' statements. No scope confusion risk. Confidence: 0.99 - Clearly SQL syntax in Postgres documentation.

عوامل الخطر

⚡ يحتوي على سكربتات (1)
⚙️ الأوامر الخارجية (2)
🌐 الوصول إلى الشبكة (2)
تم تدقيقه بواسطة: claude

درجة الجودة

38
الهندسة المعمارية
100
قابلية الصيانة
87
المحتوى
50
المجتمع
92
الأمان
91
الامتثال للمواصفات

ماذا يمكنك بناءه

استكشاف أخط��ء أداء الاستعلام

يستخدم المطور الذي يعاني من نقاط نهاية API بطيئة قواعد تحسين الاستعلام لإضافة فهارس وإعادة كتابة الاستعلامات لتحسين 100-1000 مرة.

مراجعة تصميم مخطط قاعدة البيانات

يراجع مهندس قواعد البيانات قواعد تصميم المخطط قبل إطلاق تطبيق SaaS متعدد المستأجرين لتجنب إعادة الهيكلة المكلفة.

تخطيط ترحيل Postgres

يخطط مهندس DevOps للترحيل من البنية الأحادية المستأجر إلى متعددة المستأجرين باستخدام إرشادات RLS وتجميع الاتصالات.

جرّب هذه الموجهات

تحسين الاستعلام الأساسي
لدي استعلام Postgres بطيء. ساعدني في تحسينه باستخدام أفضل الممارسات من مهارة supabase-postgres-best-practices.

استعلامي:
```sql
SELECT * FROM orders WHERE customer_id = 123 AND status = 'pending'
```

الجدول يحتوي على 10 ملايين صف. الاستعلام يستغرق 5 ثوانٍ.
مراجعة استراتيجية الفهرسة
راجع استراتيجية الفهرسة الخاصة بهذا المخطط باستخدام مهارة supabase-postgres-best-practices. ركز على الفهارس المركبة والفهارس الجزئية وفهرسة المفاتيح الأجنبية.

المخطط:
- جدول users (1 مليون صف)
- جدول orders (5 ملايين صف، مفتاح أجنبي لـ users)
- نمط الاستعلام: التصفية المتكررة عبر user_id + created_at + status
تحسين سياسات RLS
أقوم بتطبيق أمان المستوى الصف للبيانات متعددة المستأجرين باستخدام supabase-postgres-best-practices. ساعدني في تحسين سياسات RLS.

السياسة الحالية:
```sql
CREATE POLICY user_isolation ON documents
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);
```

تدهور أداء الاستعلام 5 مرات بعد تفعيل RLS.
تكوين تجميع الاتصالات
ساعدني في تكوين تجميع الاتصالات لتطبيق Node.js مع Supabase باستخدام supabase-postgres-best-practices.

المتطلبات:
- 1000 مستخدم متزامن
- متوسط وقت الاستعلام: 50 مللي ثانية
- استخدام PgBouncer
- مواجهة أخطاء استنزاف الاتصالات

قدم قيم تكوين محد��ة واشرح المفاضلات.

أفضل الممارسات

  • أنشئ دائماً فهارس على أعمدة WHERE و JOIN و ORDER BY قبل النشر إلى الإنتاج
  • استخدم ترقيم المؤشر مع الأعمدة المفهرسة بدلاً من OFFSET لمجموعات النتائج الكبيرة
  • احتفظ بالمعاملات قصيرة (أقل من ثانية واحدة) وتجنب تفاعل المستخدم في منتصف المعاملة لمنع تضارب الأقفال

تجنب

  • استخدام SELECT * على الجداول الكبيرة عند الحاجة فقط لأعمدة محددة (يسبب إدخال/إخراج غير ضروري ويمنع تحسين فهرس التغطية)
  • تشغيل عبارات INSERT فردية داخل الحلقات بدلاً من تجميع الصفوف أو استخدام COPY
  • إنشاء فهارس دون تحليل أنماط الاستعلام مع EXPLAIN ANALYZE (بعض الفهارس قد تضر أداء الكتابة دون مساعدة القراءة)

الأسئلة المتكررة

كيف أعرف أي الأعمدة تحتاج فهارس؟
استخدم استعلام الفهارس المفقودة من query-missing-indexes.md لتحديد الأعمدة التي يتم الوصول إليها بشكل متكرر بدون فهارس. شغل EXPLAIN ANALYZE على الاستعلامات البطيئة لاكتشاف الفحوصات المتسلسلة. أولوِ أعمدة WHERE و JOIN المستخدمة في الاستعلامات الحرجة للتطبيق.
هل يجب فهرسة كل مفتاح أجنبي؟
نعم دائماً تقريباً. وفقاً لـ schema-foreign-key-indexes.md، توفر فهارس المفاتيح الأجنبية تحسيناً 5-20 مرة لـ JOINs وتمنع مشاكل أداء DELETE المتتالي. تجاوزها فقط إذا لم يتم الاستعلام عن العمود أو الانضمام إليه أبداً.
لماذا الترقيم القائم على المؤشر أفضل من OFFSET؟
يتطلب OFFSET فحص وتجاهل جميع الصفوف السابقة، ليصبح أبطأ مع الترقيم الأعمق. الترقيم القائم على المؤشر (باستخدام بنود WHERE مفهرسة) له أداء O(1) بغض النظر عن عمق الصفحة. راجع data-pagination.md لأمثلة التنفيذ.
كم عدد مجمعات الاتصالات التي أحتاجها لـ Supabase؟
من conn-pooling.md: استخدم PgBouncer في وضع المعاملة. يجب أن يكون حجم التجمع (عدد خوادم التطبيقات × الاتصالات لكل خادم). لـ 1000 مستخدم متزامن مع استعلامات 50 مللي ثانية، ابدأ بحجم تجمع 20-50 وراقب أخطاء الاستنزاف.
هل يؤثر أمان المستوى الصف (RLS) على الأداء؟
نعم، يمكن أن يضيف RLS حملاً 2-5 مرة إذا كانت السياسات غير مثلى. يشرح security-rls-performance.md استخدام فهارس على أعمدة السياسة، وتجنب الاستعلامات الفرعية في السياسات، واستخدام طرق العرض security_invoker. سياسات RLS المضبوطة بشكل صحيح تحافظ على الأمان بتكلفة أداء ضئيلة.
هل يمكنني استخدام هذه القواعد مع PostgreSQL الخام أو Supabase فقط؟
جميع القواعد الأساسية تنطبق على PostgreSQL الخام. ملاحظات Supabase الخاصة (إعدادات ت��ميع الاتصالات الافتراضية، RLS المُدار) محددة بوضوح. قواعد الفهرسة وتحسين الاستعلام وتصميم المخطط تعمل بشكل متطابق في أي نشر Postgres 14+.