لماذا نستخدم الفهرسة في قواعد البيانات Database Index و MySQL

تفيد الفهرسة في تسريع الوصول للبيانات في الجدول عند البحث (خاصة عند كتابة الشروط) وكما نعلم عندما تكون لدينا بيانات مرتبة، تصبح عملية البحث أسرع حيث أن أغلب خوارزميات البحث تعتمد على بيانات مرتبة. مثلاً خوارزمية البحث الثنائي.

الفهرس في قاعدة البيانات هو ملف (أو أكثر) يحوي على قيم عمود ما من الجدول ولكن بطريقة مرتبة، وكل قيمة تحوي ارتباط لموقعها الفعلي في الجدول (مثل مؤشر أو رابط) فعندما نريد تطبيق شرط ما على عمود في الجدول، نبحث ضمن الفهرس (لسرعة البحث) ثم يرشدنا الفهرس لمكان البيانات الفعلية (سطر جدول قاعدة البيانات الفعلي) وهنا نسترجع بيانات كامل السجل.

مثلا من الجيد استخدام حقل اللإيميل وعمل فهرسة عليه.

SELECT * 
FROM Employee 
WHERE email = 'wael@hsoub.com'

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

# إنشاء فهرس أو أكثر لجدول ما

CREATE INDEX [ name ] ON tbl ( col [, ...]);


# إنشاء فهرس لتسريع البحث حسب اسم المقالة

CREATE INDEX index_title ON posts (title);

القيود على إنشاء الفهارس أن تكون قيمة الهود رقمية أو نصية varchar (لا يقبل text) حتى تكون الفهرسة نافعة وسريعة.

للفهرس معامل مهم هو fillfactor (معامل الملئ) وهذا يحدد نسبة حشو ملفات الفهرسة، لأننا نعلم أن البيانات تزيد باستمرار ولضمان ترتيبهم ضمن الفهرس في ملفات، علينا إبقاء مساحة فارغة فيهم لضمان وضع البيانات الجديدة في ترتريب سليم بدون الإضطرار لوضعهم في ملفات أخرى وعمل روابط تنقل بين صفحات الفهارس ومثلا نسبة الحجز للملف نضعهم 75%..

حذف فهرس
DROP INDEX [ IF EXISTS ] name [ CASCADE | RESTRICT ]

تعديل فهرس
ALTER INDEX [ IF EXISTS ] name RENAME TO new_name
ALTER INDEX distributors SET (fillfactor = 75);

قاعدة مهمّة أخرى عند استخدام الفهارس هي أنه ينبغي الانتباه إلى ربط الجداول (عبر التعليمة join مثلا)؛ إذ يجب أن تُنشَأ فهارس للحقول المستخدمة في الربط، كما يجب أن تشترك هذه الحقول في نوع البيانات.

تشبه فهرسة الكتب، الهدف منها تسريع البحث.

بالإضافة إلى إجابة أستاذ وائل, فإن بيانات الفهرس يتم تخزينها على شاكلة هيكل بيانات الشجرة المتوازنة(b+tree) والتي تعتمد في طريقة تخزينها على أن يحمل كل عنصر في الهيكل ثﻻث معلومات

1. قيمة العنصر
2. مؤشر(pointer) يُشير إلى العنصر على يمينه
3. مؤشر(pointer) يُشير إلى العنصر على يساره  

وتعتمد الأشجار المتوازنة في ألية عملها على أن دائما وأبداً يكون كل عنصر أكبر من العناصر على يمينه , وأصغر من العناصر على يساره مما يُسهل عملية البحث ويجعلها في أسوأ الحالات تأخذ تعقيد وقتي قيمته O(logn) فعندما نريد إذاً البحث عن عنصر ما في قاعدة البيانات ﻻ نحتاج أن نمر على جميع العناصر وإنما فقط نقوم بالمرور على عدد من العناصر يساوي لوغاريتم العنصر للأساس 2 في أسوأ الحالات

ومن الممكن تحديد هيكل البيانات المُستخدم أن يكون من النوع جدول التجزئة( hash table) والذي يعتمد في ألية عمله أن يكون على هيئة القيمة والمفتاح (key&value) فيتم تخزين ناتج تجزئة مفتاح( element hashing) في المصفوفة الخاصة بالجدول, وعند الإحتياج للوصول إليه يتم ذلك في تعقيد وقتي O(1) حيث أن ناتج التجزئة يكون ثابت دائماً فﻻ نحتاج إذا للبحث, ولكن في الحياة العملية ﻻ يتم إستخدام الجدول بسبب وجود عدد من المشاكل مثل

1. إن تم تخزين أكثر من مفتاح لهم نفس ناتج التجزئة(hashing) تحدث حالة تداخل(collision) فيتم تخزين كلا العنصرين في قائمة ويتم تخزين تلك القائمة في العنصر في المصفوفة, وكثرة التداخلات تُسبب إستهﻻك للموارد وأداء سيئ نسبياً
2. ﻻ تعمل جيداً مع العمليات التي نحتاج فيها إلى إستخدام معاملات أكبر من, أو أصغر من , تعمل فقط مع معامل المساواة فمثلاً جملة مثل

   select * from student where indx>5

   سيتم معالجتها بأداء سيئ عند إستخدام جدول التجزئة حيث أنه ﻻ يقوم بتخزين قيمة الفهرس وإنما يٌخزن قيمة التجزئة , فسيكون التعقيد الوقتي هنا مساوي لO(n)