لدى مارك لوحة معلومات تعرض طلبات يوم مختار، وقد أصبحت بطيئة على قاعدة البيانات الإنتاجية. «الـ query نفسه كالعادة. لماذا صار بطيئًا فجأة؟». على طلبات Cartwheel التي تبلغ ألفين، يعيد كل query في هذه الدورة نتيجته فورًا. أما بيئة الإنتاج ففيها سنوات من الطلبات، وهناك يكون الفرق بين query يقرأ كل صف وآخر يقفز إلى الصفوف الصحيحة فرقًا بين ثوانٍ ودقائق. لا يمكنك أن تشعر بهذا الفرق على قاعدة بيانات صغيرة، لكن يمكنك أن تراه في خطة التنفيذ (query plan).
\nالـ index بنية منفصلة تحفظ قيم عمود أو أكثر مرتّبة، مع مؤشّر من كل قيمة إلى صفها. إيجاد ‘2025-11-28’ في قائمة مرتّبة يشبه إيجاد كلمة في قاموس: تقفز إلى الصفحة الصحيحة على وجه التقريب بدل القراءة من البداية. بدون index، تضطر قاعدة البيانات إلى قراءة الجدول كله واختبار كل صف، وهذا هو المسح (scan).
\nفي قاعدة بيانات Cartwheel بعض الـ indexes بالفعل. يمكنك عرضها من جدول المخطط:
\nSELECT name, tbl_name, sql\nFROM sqlite_schema\nWHERE type = 'index';على orders يوجد index على customer_id وآخر على order_date، وعلى order_items index على order_id وآخر على product_id. أما المدخل sqlite_autoindex_customers_1 فموجود لأن email معرّف كـ UNIQUE؛ ويفرض SQLite التفرّد باستخدام index.
ضع EXPLAIN QUERY PLAN قبل أي SELECT، فيصف SQLite كيف سينفّذه بدل أن ينفّذه. الجزء المهم هو العمود detail:
EXPLAIN QUERY PLAN\nSELECT order_id, status\nFROM orders\nWHERE order_date >= '2025-11-28'\n AND order_date < '2025-11-29';SEARCH orders USING INDEX idx_orders_date (order_date>? AND order_date<?). تعني SEARCH أن الـ index ضيّق العمل إلى نطاق. والآن الـ query الخاص بلوحة مارك، الذي «بسّطه» أحدهم الشهر الماضي:
EXPLAIN QUERY PLAN\nSELECT order_id, status\nFROM orders\nWHERE date(order_date) = '2025-11-28';SCAN orders. النتيجة نفسها، لكن الآن يُقرأ كل صف وتُحسب date() لكل واحد منها. يخزّن الـ index قيم order_date الخام؛ ولا يعرف شيئًا عن date(order_date)، فلا يستطيع المساعدة. هذا هو «البطء المفاجئ».
هناك عبارتان أخريان في الخطط تستحقان أن تتعرّف عليهما. USING COVERING INDEX تعني أن الـ index وحده احتوى على كل عمود احتاجه الـ query، فلم يُلمس الجدول إطلاقًا، وهذا أسرع أنواع البحث. وUSE TEMP B-TREE FOR GROUP BY أو FOR ORDER BY تعني أن SQLite اضطر إلى ترتيب الصفوف بنفسه، وهذا مقبول مع النتائج الصغيرة ويستحق نظرة مع الكبيرة.
خطط الـ JOIN تعرض سطرًا لكل جدول، بالترتيب الذي يزورها به SQLite:
\nEXPLAIN QUERY PLAN\nSELECT o.order_id, SUM(oi.quantity) AS units\nFROM orders AS o\nJOIN order_items AS oi ON oi.order_id = o.order_id\nWHERE o.customer_id = 42\nGROUP BY o.order_id;السطران كلاهما SEARCH: اعثر على طلبات العميل 42 عبر idx_orders_customer، ثم على عناصر كل طلب عبر idx_items_order. وجود index على كل مفتاح أجنبي تربط به هو أثمن عادة منفردة في الفهرسة.
خطة التنفيذ هي اختيار المُحسِّن (optimizer)، لا ضمان للسرعة، وهي تعتمد على البيانات. في جدول صغير جدًا قد يقرّر المُحسِّن أن المسح أرخص من الـ index، وسيكون محقًا. يستطيع المحرّكان كلاهما الاحتفاظ بإحصاءات عن كل جدول يجمعها الأمر ANALYZE (في PostgreSQL تشغّله عملية autovacuum تلقائيًا، أما في SQLite فلا بد أن يشغّله أحد)، ويستخدمانها لتقدير عدد الصفوف التي تعيدها كل خطوة. حين تصبح هذه الإحصاءات قديمة، تخطئ الخطط بطرق مفاجئة، وهذا سؤال آخر تطرحه على صاحب قاعدة البيانات بشأن query تباطأ «بلا سبب».
بعض الشروط لا تستطيع استخدام index عادي مهما كتبتها. name LIKE '%mat%' يضطر إلى النظر داخل كل قيمة، لأن القائمة المرتّبة لا تساعدك في إيجاد نص في منتصف الكلمات. إذا كان بحث كهذا متكرّرًا، فالحل أداة مختلفة، مثل البحث النصي الكامل (full-text search)، لا index إضافي.
كثيرًا ما لا يملك المحلّلون المخطط، لكنك ستكون من يلاحظ الـ query البطيء. يصفّي فريق الدعم التذاكر حسب opened_at باستمرار، ولا يوجد index على هذا العمود، فتكون خطة هذه الـ queries مسحًا (SCAN). والطلب الذي سترفعه إلى صاحب قاعدة البيانات سيكون:
CREATE INDEX idx_tickets_opened_at ON support_tickets (opened_at);الـ indexes ليست مجانية. كلٌّ منها يأخذ مساحة تخزين ويجب تحديثه مع كل إدراج وتحديث وحذف، فالجدول الذي عليه عشرة indexes يكتب أبطأ بشكل ملحوظ. اطلب indexes على أعمدة تصفّي عليها queries متكرّرة أو تربط بها أو ترتّب حسبها، وتضيّق النتيجة كثيرًا. الـ index على status، الذي له خمس قيم فقط، نادرًا ما يساعد؛ أما الـ index على تاريخ أو معرّف فيساعد عادةً. وفي الـ index متعدّد الأعمدة، ضع أولًا العمود الذي تختبره بـ = ثم عمود النطاق: (customer_id, order_date) يخدم «طلبات العميل 42 في 2025» ببحث واحد.
الـ queries السريعة لا تنفع إلا إذا استطاع الناس قراءتها. في الدرس التالي: عادات الأسلوب وفروق اللهجات التي تجعل SQL الذي تكتبه قابلًا للمراجعة والنقل.
\n","toc":[{"id":"sec-1","text":"ما هو الـ index","level":2},{"id":"sec-2","text":"قراءة خطة التنفيذ","level":2},{"id":"sec-3","text":"الخطط تنبؤات","level":2},{"id":"sec-4","text":"متى تطلب index جديدًا","level":2}],"takeaways":["الـ index نسخة مرتّبة من عمود أو أكثر مع مؤشّرات تعود إلى الصفوف، فتستطيع قاعدة البيانات القفز إلى القيم المطابقة بدل قراءة كل صف.","في EXPLAIN QUERY PLAN تعني SEARCH … USING INDEX أن الـ index ضيّق العمل؛ وتعني SCAN أن كل صف (أو كل مدخل في الـ index) قد قُرئ.","وضع عمود عليه index داخل دالة أو عملية حسابية، مثل date(order_date)، يمنع عادةً استخدام الـ index؛ قارن العمود المجرّد بنطاق بدل ذلك.","الـ indexes تسرّع القراءة لكنها تكلّف مساحة تخزين وتبطئ كل إدراج وتحديث، لذا أضفها للشروط المتكرّرة والانتقائية ولمفاتيح الربط."],"further":[{"title":"SQLite EXPLAIN QUERY PLAN","url":"https://www.sqlite.org/eqp.html"},{"title":"SQLite query optimizer overview","url":"https://www.sqlite.org/optoverview.html"},{"title":"PostgreSQL using EXPLAIN","url":"https://www.postgresql.org/docs/current/using-explain.html"}],"quiz":[{"q":"على orders يوجد index على order_date. أي شرط لطلبات 28 نوفمبر 2025 يستطيع استخدامه كـ SEARCH؟
WHERE date(order_date) = '2025-11-28'","why":"يخزّن الـ index قيم order_date الخام لا date(order_date)، فتضطر قاعدة البيانات إلى حساب الدالة لكل صف."},{"text":"WHERE strftime('%Y-%m-%d', order_date) = '2025-11-28'","why":"المشكلة نفسها بدالة مختلفة؛ أي تعبير يحيط بالعمود يخفيه عن الـ index."},{"text":"WHERE order_date >= '2025-11-28' AND order_date < '2025-11-29'","why":"صحيح. العمود المجرّد يُقارَن بثوابت، فتستطيع قاعدة البيانات الانتقال إلى بداية النطاق في الـ index المرتّب والتوقف عند نهايته."}],"answer":2},{"q":"تعرض خطة التنفيذ SCAN orders USING COVERING INDEX idx_orders_date. ماذا يعني ذلك؟
قاعدة بيانات تحليلية تستقبل مليون جلسة ويب جديدة يوميًا، ويُستعلم منها بضع مرات يوميًا حسب source. يقترح أحدهم indexes على الأعمدة التسعة كلها في web_sessions. ما أفضل رد؟
customer_id فقط، لأن المعرّفات هي دائمًا أفضل index.","why":"أفضل index هو الذي يطابق طريقة الاستعلام من الجدول. لا شيء في هذا السيناريو يصفّي حسب العميل."},{"text":"ضع indexes على الأعمدة التي تصفّي عليها queries حقيقية متكرّرة أو تربط بها، وافحص الخطط، وتجاهل الباقي.","why":"صحيح. لكل index تكلفة كتابة وتخزين، فأضف ما يخدم queries فعلية وتأكّد بـ EXPLAIN QUERY PLAN أنها مستخدمة."}],"answer":3},{"q":"في PostgreSQL، ماذا يفعل EXPLAIN ANALYZE ولا يفعله EXPLAIN؟
تعرض لوحة مارك الطلبات لكل يوم في عطلة نهاية أسبوع Black Friday، من الجمعة 28 نوفمبر إلى الاثنين 1 ديسمبر 2025 شاملًا (كل الحالات).
\nأعِد day (‘YYYY-MM-DD’) وorders، مرتّبة حسب day. الترتيب مهم. شرط الكود المبدئي متوافق مع الـ index لكنه يُسقط يومًا كاملًا.
أصلحه حتى تكون النتيجة كاملة ويبقى الشرط مستخدمًا لـ idx_orders_date: شغّل الـ query الخاص بك مع EXPLAIN QUERY PLAN قبله وتحقّق من أن الخطة تقول SEARCH لا SCAN.
date(order_date) BETWEEN ...، ستصلح العدد لكنها ستحوّل الخطة إلى SCAN.","استخدم نطاقًا نصف مفتوح على العمود المجرّد: order_date >= '2025-11-28' AND order_date < '2025-12-02'."],"explanation":"يتوقف BETWEEN '2025-11-28' AND '2025-12-01' عند منتصف الليل في بداية 1 ديسمبر، فيختفي Cyber Monday. أما date(order_date) BETWEEN ... فيعيد الصفوف الصحيحة لكنه يجعل SQLite يحسب date() لكل طلب، أي مسحًا كاملًا. النطاق نصف المفتوح يُبقي العمود المفهرس مجرّدًا في أحد طرفي كل مقارنة، فتقول الخطة SEARCH orders USING COVERING INDEX idx_orders_date، ويشمل يوم الاثنين كله: 15 و12 و11 و4 طلبات.