Database Indexes للمبتدئ: من 8 ثواني لـ 5 مللي ثانية بسطر SQL

-- 1. قياس قبل الـ Index
EXPLAIN ANALYZE
SELECT * FROM users WHERE email = 'ahmed@example.com';

-- النتيجة:
-- Seq Scan on users (cost=0.00..32841.00 rows=1 width=84)
-- Execution Time: 8423.521 ms

-- 2. إنشاء الـ Index (سطر واحد)
CREATE INDEX idx_users_email ON users(email);

-- 3. قياس بعد الـ Index
EXPLAIN ANALYZE
SELECT * FROM users WHERE email = 'ahmed@example.com';

-- النتيجة:
-- Index Scan using idx_users_email on users
-- Execution Time: 4.987 ms

سطر CREATE INDEX واحد. النتيجة: 1690x أسرع. لازم تلاحظ كلمة Index Scan في خطة الاستعلام بدل Seq Scan؛ دي اللي بتأكدلك إن الـ Index اتستخدم فعلاً.

متى الـ Index بيشتغل ومتى لا

الـ Index مش سحر. بيشتغل في حالات محددة، وبيتجاهله الـ planner في حالات تانية:

• WHERE email = 'x@y.com' ← بيشتغل (equality match مباشر).
• WHERE email LIKE 'ahm%' ← بيشتغل (prefix match، بداية معروفة).
• WHERE email LIKE '%example.com' ← ما بيشتغلش (suffix match، الـ B-tree مرتّبة من اليمين، مش من الشمال).
• WHERE LOWER(email) = 'a@b.com' ← ما بيشتغلش إلا لو عملت expression index: CREATE INDEX ON users(LOWER(email)).

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

الـ Index مش مجاني. كل سطر CREATE INDEX ليه ثمن:

1. مساحة قرص. Index على عمود email في جدول 1.2M صف بياخد ~80MB إضافية. على 10 indexes، الجدول ممكن يبقى ضعف حجمه.
2. بطء INSERT و UPDATE و DELETE. كل عملية كتابة لازم تحدّث كل index على الجدول. على benchmarks فعلية، INSERT بقى أبطأ بـ 12-18% بعد إضافة 4 indexes.
3. صيانة دورية. الـ Indexes بتتعرّض لـ bloat بعد كتير من الـ updates، فلازم REINDEX كل فترة، وده بيقفل الجدول لو مستخدمتش CONCURRENTLY.

الافتراض هنا: عندك جدول قراءته أكتر بكتير من كتابته (نسبة 80/20 أو أعلى). لو الجدول write-heavy، الحساب بيتغيّر.

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

• الجدول صغير (أقل من 10,000 صف). Sequential Scan أسرع لأن الـ planner بيحسب إن قراءة الجدول كله من الذاكرة أرخص من البحث في الـ Index.
• عمود بقيم متكررة بشدة. مثلاً عمود is_active فيه true على 95% من الصفوف. الـ Index هنا تقريباً عديم الفايدة، الـ DB هتفضل تعمل scan.
• جداول write-heavy والقراءات نادرة. زي logs و audit_trail. تكلفة تحديث الـ Index في كل INSERT هتفوق فايدة الـ SELECT اللي بتحصل مرة في اليوم.
• أعمدة بتتغير قيمتها كتير. Index على عمود بيتعدّل في كل request هيخلق bloat بسرعة.

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

افتح PostgreSQL عندك دلوقتي ونفّذ الاستعلام ده:

لو لقيت Indexes بـ idx_scan = 0، دي Indexes بتشغل مساحة وبتبطّأ الكتابة بدون أي فايدة. احذفها بـ DROP INDEX idx_name; ولاحظ الـ INSERT بيرجع أسرع. ابعتلي مخرجات الاستعلام لو في حاجة مش واضحة.

المصادر

• PostgreSQL 16 Documentation - Indexes: postgresql.org/docs/16/indexes.html
• Bayer & McCreight, "Organization and Maintenance of Large Ordered Indexes" (1972) - الورقة الأصلية للـ B-tree.
• Markus Winand, "Use The Index, Luke!" - use-the-index-luke.com
• PostgreSQL Wiki - Index Maintenance: wiki.postgresql.org/wiki/Index_Maintenance