استراتيجيات فهرسة قواعد البيانات للمطورين

الاستعلام الذي غيّر كلّ شيء

تغيّرت علاقتي بفهارس قاعدة البيانات اليوم الذي سألني فيه مهندس مبتدئ لماذا كان استعلامه بطيئاً. قلت بثقة إنّه يحتاج فهرساً، وأضفت واحداً، فأصبح الاستعلام أبطأ. ليس لأنّ الفهرس كان خاطئاً — بل كان بالضبط الفهرس الصحيح للاستعلام — لكن لأنّ الجدول كان لديه تسعة فهارس أخرى يوازنها المحسّن الآن ضدّ بعضها، والإحصاءات التي يستخدمها للاختيار صارت بالية. علّمني ذلك اليوم أن الفهرسة ليست قائمة تحقّق؛ بل نموذج لكيفيّة استنتاج قاعدة بياناتك لبياناتك، والنموذج يتغيّر كما تتغيّر البيانات.

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

قراءة خطة EXPLAIN دون خوف

خطة EXPLAIN أداة التشخيص التي تفصل المطوّرين الذين يضبطون قواعد البيانات عن الذين يخمّنون. قراءتها مهارة، ومثل أيّ مهارة، تُكافئ الممارسة المتعمّدة. تخبرك الخطة بما قرّرت قاعدة البيانات فعله، لا بما أردت منها فعله، والفجوة بينهما هي حيث يعيش الأداء.

• Seq Scan — قاعدة البيانات تقرأ كلّ صف. أحياناً هذا صحيح (الجداول الصغيرة، العمليات الدفعيّة)؛ غالباً يعني فهرساً مفقوداً أو غير مستخدم.
• Index Scan — قاعدة البيانات تستخدم فهرساً لإيجاد الصفوف. جيّد، لكن تحقّق ما إذا كانت تجلب بيانات الصف بعد ذلك (جلب كومة)، وهو ما قد يكون مكلفاً.
• Index Only Scan — وجدت قاعدة البيانات كلّ ما تحتاجه في الفهرس دون لمس الجدول. الكأس المقدّس؛ قابل للتحقيق حين تكون كلّ الأعمدة المستعلام عنها في الفهرس.
• Nested Loop مقابل Hash Join — يخبرك كيف تربط قاعدة البيانات الجداول. الوصلات المتجزّئة عادة أسرع للمداخل الكبيرة؛ حلقات التعشيش تفوز حين يكون جانب صغيراً.

بصيرة الفهرس المركّب

أكثر مفهوم فهرسة تأثيراً للمطوّرين هو الفهرس المركّب، وتحديداً ترتيب الأعمدة داخله. الفهرس المركّب على (الاسم_الأخير، الاسم_الأوّل) يخدم الاستعلامات التي ترشّح على الاسم_الأخير وحده، أو على كلا العمودين، لكن لا يخدم الاستعلامات التي ترشّح على الاسم_الأوّل وحده. الفهرس قابل للاستخدام من اليسار إلى اليمين، وهذه الخاصيّة — تُسمّى قاعدة البادئة اليسرى — تحدّد أيّ الاستعلامات تستفيد وأيّها لا.

الفهرس الذي لا تستخدمه ليس محايداً؛ بل مسؤوليّة. يكلّف أداء الكتابة والتخزين واعتبار المحسّن عند كلّ استعلام. أفضل فهرس هو الذي تزيله، لا الذي تضيفه.

حين تكون الفهارس الجواب الخطأ

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

الدرس الأعمق هو أنّ الأداء خاصيّة النظام كلّه، لا مكوّن واحد. الاستعلام البطيء قد يحتاج فهرساً، أو قد يحتاج مخطّطاً مختلفاً، أو قد يحتاج تخزيناً مؤقّتاً، أو قد يحتاج تجربة مستخدم مختلفة لا تطرح السؤال أصلاً. المطوّر الذي يمدّ يده إلى الفهرس بانعكاسيّة كالنجّار الذي يمدّ يده إلى المطرقة بصرف النظر عن المثبّت. الفهارس أداة واحدة في حقيبة أدوات أكبر، والممارس الماهر يعرف أيّ أداة تتطلّبها الوظيفة فعلاً. الفضول حول النموذج الأساسي — حول كيفيّة استنتاج قاعدة البيانات — هو ما يفصل عمل الأداء الكافي عن عمل الأداء الممتاز.