Database Index بالعربي: ليه استعلام بياخد 8 ثواني والثاني 12ms

دلوقتي اعمل Index على نفس العمود. في الإنتاج، استخدم CONCURRENTLY علشان متقفلش الجدول على كتابات تانية:

الفرق بين 7843ms و11.4ms ده ~688× أسرع، على نفس الجدول، نفس الكود، نفس الداتا. غيّرت سطر واحد بس. الكلمة CONCURRENTLY مهمة في الإنتاج: بتسمح بإنشاء الـ Index بدون ACCESS EXCLUSIVE lock، يعني التطبيق هيشتغل عادي طول مدة الإنشاء.

Composite Index: لما عندك أكتر من شرط

لو الـ WHERE بياخد عمودين (customer_email = ? AND status = 'paid')، Index على عمود واحد لوحده مش هيغطي الحالة بالكامل. الحل: Composite Index على العمودين بترتيب اللي بيفلتر أكتر الأول:

الترتيب مهم. هذا الـ Index هيشتغل للـ queries اللي فيها customer_email لوحده، أو customer_email + status. لكنه مش هيشتغل لو فلترت بـ status لوحده. القاعدة: العمود الأكثر تحديدًا (selectivity) في الأول.

Trade-offs اللي لازم تعرفها

الـ Index مش مجاني. كل INSERT أو UPDATE أو DELETE بيحدّث الجدول وبيحدّث كل Index على الجدول. على جدول فيه 5 Indexes، الكتابة بتاخد ~30-50% وقت زيادة لكل عملية. غير كده، الـ Index بياخد مساحة قرص. على جدول 50GB، Index على عمود VARCHAR(255) ممكن ياخد 4-8GB لوحده.

الافتراض هنا إن نسبة القراءة للكتابة في تطبيقك أعلى من 5:1، اللي بيكون صحيح في معظم تطبيقات الويب التقليدية. لو بتكتب أكتر بكتير من ما بتقرا (مثلاً جدول events للـ telemetry بيستقبل 10 آلاف INSERT في الثانية)، فكر مرتين قبل ما تضيف Index على عمود بيتكتب فيه باستمرار.

متى لا تستخدم Index

• أعمدة فيها تنوّع منخفض جدًا: عمود is_active BOOLEAN بقيمتين بس. الـ planner هيتجاهل الـ Index ويرجع لـ Sequential Scan لأن الـ Index أبطأ في الحالة دي.
• جداول صغيرة (< 10 آلاف صف): تكلفة قراءة الـ Index ممكن تطلع أعلى من قراءة الجدول كله من الـ memory. PostgreSQL بيحتفظ بالجداول الصغيرة في الـ shared_buffers على طول.
• أعمدة بتتحدّث بمعدل عالي: عمود last_seen TIMESTAMP بيتحدّث في كل request. الـ Index هيتعمله rewrite في كل update، والتكلفة بتاكل المكسب.
• بحث بنهاية النص: WHERE email LIKE '%@gmail.com' مش هيستفيد من B-tree. محتاج pg_trgm Index بدل ما تضيف B-tree غلط.

أخطاء شائعة في الـ Indexing

أول خطأ: إضافة Index على كل عمود في الجدول "تحسبًا". ده بياكل مساحة وبيبطّأ الكتابة بدون فايدة قابلة للقياس. ابدأ بالـ Indexes اللي EXPLAIN ANALYZE أثبت إنها بتحوّل Seq Scan لـ Index Scan فعلًا.

تاني خطأ: نسيان CONCURRENTLY في الإنتاج. CREATE INDEX بدون CONCURRENTLY بياخد ACCESS EXCLUSIVE LOCK على الجدول طول مدة الإنشاء، اللي ممكن يكون دقايق على جدول كبير. التطبيق هيوقف فعليًا.

ثالث خطأ: الاعتماد على Index واحد بدون مراقبة استخدامه. pg_stat_user_indexes بيقولك أي Indexes اتقرأ منها فعلًا. Index ميتقريش منه بعد شهر = Index ممكن تشيله.

الخطوة التالية

افتح أبطأ 5 استعلامات في تطبيقك من pg_stat_statements (أو slow query log في MySQL). شغّل EXPLAIN ANALYZE على كل واحد. أي استعلام بيرجع Seq Scan على جدول > 50 ألف صف، اعمل Index على عمود الـ WHERE الأساسي بـ CONCURRENTLY واقيس قبل وبعد. لو الفرق أقل من 10×، الـ Index غالبًا مش حلّ المشكلة، وفيه حاجة تانية: JOIN غلط، ORDER BY على عمود غير مفهرس، أو إن الـ planner بيختار الخطة الغلط بسبب statistics قديمة (شغّل ANALYZE).

المصادر

• PostgreSQL Documentation — Indexes: postgresql.org/docs/current/indexes
• PostgreSQL — CREATE INDEX CONCURRENTLY: postgresql.org/docs/current/sql-createindex
• PostgreSQL — Monitoring Stats & pg_stat_user_indexes: postgresql.org/docs/current/monitoring-stats
• MySQL Reference Manual — Optimization and Indexes: dev.mysql.com/doc/refman/8.0/en/optimization-indexes
• Use The Index, Luke! — Anatomy of an Index: use-the-index-luke.com/sql/anatomy