الفهارس وأشجار B

كيف يمكن لقاعدة البيانات العثور على سجل واحد بين ملايين الصفوف في أجزاء من الثانية؟

افتراضيًا، عندما نسأل SELECT * FROM customers WHERE city = 'Milano'، يتعين على Postgres إجراء مسح تسلسلي: فهو يقرأ فعليًا الجدول بأكمله من صف على القرص، ويقارن كل مدينة بـ "ميلانو". عندما يحتوي الجدول على ملايين السجلات، فإن هذه العملية تؤدي إلى إعاقة الأداء.

إن الإجابة الهيكلية الرئيسية على هذه الاختناقات هي الفهارس.

الفهارس (B-Trees)

تعمل المؤشرات تمامًا مثل المؤشر التحليلي الموجود في الجزء الخلفي من كتاب كبير. بدلاً من قراءة الكتاب بأكمله للعثور على المكان الذي يتحدث فيه عن "ميلانو"، فإننا نبحث في الصفحات الخلفية حيث تعيد كلمة "ميلانو" توجيهنا إلى [p. 45, 114, 230]. تقوم قواعد البيانات، خلف الكواليس، ببناء بنية بيانات منفصلة ومدمجة للغاية (غالبًا "B-Tree") مرتبة حسب العمود أو الأعمدة المعنية، وتحتوي على مؤشرات مباشرة للتخزين الفعلي للصفوف المطابقة.

-- Creare un indice semplice
CREATE INDEX idx_customers_city ON customers(city);

تؤدي هذه العملية الفردية إلى تشغيل محرك Postgres، الذي سيقوم باستخراج وفهرسة كافة قيم city في الخلفية. بمجرد الانتهاء، سيتم نقل كل SELECT ... WHERE city = '...' اللاحقة!

المفاتيح الأساسية والتفرد

هل تعلم أن القواعد الأساسية للمفتاح الأساسي (PRIMARY KEY) وUNIQUE تستخدم الفهارس بشكل سري أسفل الغطاء؟ نظرًا لأن قاعدة البيانات يجب أن تتأكد من عدم تكرار البريد الإلكتروني أو المعرف مطلقًا عند إدراج صفوف أو تعديلها، فإن PostgreSQL يقوم تلقائيًا بإنشاء فهرس B-Tree ضمني فوقها: بهذه الطريقة تستغرق عمليات التحقق من التفرد ميكروثانية.

ولهذا السبب فإن عمليات الانضمام في الحقل ID تتميز بأداء مذهل.

إسقاط الفهرس

إذا أدركت أن الاستعلامات الثقيلة قد تغيرت ولم تتم استشارة الفهرس مطلقًا، فمن الحكمة تدميره واستعادة المساحة الحيوية:

DROP INDEX idx_customers_city;

دورك

استكشاف الفهارس الفريدة الثانوية