كيف تعمل الفهارس في قواعد البيانات؟ شرح B-Tree و Hash Index

إذا كنت تعمل مع قواعد البيانات (سواء MySQL, PostgreSQL, SQL Server أو حتى SQLite) فغالباً سمعت عن الفهارس Indexes، وربما استخدمتها دون أن تفهم بالضبط كيف تعمل من الداخل، ولماذا أحياناً تُسرّع الاستعلامات بشكل كبير، وأحياناً أخرى تجعل الأداء أسوأ!

في هذا المقال من افهم صح سنشرح بشكل عملي:

ما هي الفهارس في قواعد البيانات ولماذا نحتاجها؟
كيف تعمل خوارزمية B-Tree المستخدمة في معظم الفهارس؟
ما هو Hash Index وكيف يختلف عن B-Tree؟
متى تستخدم كل نوع؟
أهم الأخطاء الشائعة عند استخدام الفهارس التي تبطّئ النظام بدلاً من تسريعه.

إذا أردت مقدمة عامة عن فكرة الفهرسة وأهميتها قبل الدخول في التفاصيل، يمكنك الرجوع لمقالنا: الفهرسة في قواعد البينات و أهميتها.

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

فكر في كتاب ضخم من 1000 صفحة. للعثور على موضوع معين، لديك خياران:

تقرأ الكتاب صفحة صفحة حتى تجد ما تريد (بحث خطّي).
تستخدم فهرس الكتاب في آخره، تعرف رقم الصفحة مباشرة (بحث باستخدام Index).

نفس الفكرة في قواعد البيانات:

بدون فهرس: قاعدة البيانات تضطر للمرور على كل الصفوف (Full Table Scan) لتجد الصف المطلوب.
مع فهرس: تستخدم هيكل بيانات منظم (مثل B-Tree أو Hash) للوصول لمكان الصف بسرعة كبيرة.

الكلمة المفتاحية التي نستهدفها هنا هي Database Indexing BTree لأنها تشرح أكثر أشهر نوع فهرسة مستخدم اليوم.

كيف يتم تخزين الفهرس؟ الفكرة العامة

الفهرس ليس شيئاً سحرياً، هو ببساطة:

هيكل بيانات (مثل شجرة أو جدول تجزئة).
يحتوي على قيمة العمود المفهرس (مثل id, email, username).
ومؤشر (Pointer) لمكان الصف الفعلي في الجدول (أو الصف نفسه في بعض الأنواع مثل Clustered Index).

عند تنفيذ استعلام مثل:

SELECT * FROM users WHERE email = '[email protected]';

قاعدة البيانات:

تبحث أولاً في فهرس email بدلاً من المرور على كل الصفوف.
من الفهرس تحصل على المكان (أو المفتاح الأساسي) للصف المطلوب.
تقرأ الصف من الجدول (إن كان الفهرس ثانوياً Secondary Index).

الاختلاف بين B-Tree Index وHash Index هو كيف يتم تنظيم هذه القيم داخلياً.

فهرس B-Tree: العمود الفقري لفهرسة قواعد البيانات

معظم أنظمة قواعد البيانات العلائقية (مثل MySQL InnoDB, PostgreSQL, Oracle) تستخدم نوعاً من أشجار B-Tree كخيار افتراضي للفهرسة. عندما نتحدث عن Database Indexing BTree فنحن نتحدث عن هذا النوع بالذات.

ما هي شجرة B-Tree باختصار؟

B-Tree هي شجرة متوازنة (Balanced Tree) مصممة لتقليل عدد عمليات القراءة من القرص. الفكرة الأساسية:

كل عقدة (Node) في الشجرة تحتوي على عدة مفاتيح (Keys) وليست مفتاحاً واحداً فقط.
كل عقدة يمكن أن تشير إلى عدة أبناء (Children).
الشجرة دائماً متوازنة، أي أن العمق من الجذر لأي ورقة متساوٍ تقريباً، فلا توجد فروع عميقة جداً وأخرى قصيرة.

بسبب هذا التصميم، يمكن الوصول لأي قيمة في وقت لوغاريتمي O(log n) حتى مع وجود ملايين الصفوف.

كيف يتم البحث في B-Tree؟ مثال مبسط

تخيّل أن لدينا فهرس B-Tree مبني على عمود id. عندما تبحث عن الصف الذي id = 500:

تبدأ من الجذر Root، الجذر يحتوي مثلاً على القيم:
100 | 300 | 700
تقوم بالمقارنة:
- 500 > 300 و 500 < 700 ⇒ اذهب إلى الفرع الأوسط.
العقدة التالية قد تحتوي على قيم مثل:
400 | 500 | 600
تجد 500 مباشرة أو تذهب للابن المناسب ثم تصل للقيمة.

عدد هذه الخطوات يكون قليلاً جداً مقارنة بعدد الصفوف الكلي، لأن كل عقدة تغطي نطاقاً كبيراً من القيم.

لماذا B-Tree ممتازة لعمليات >, <, BETWEEN، وفرز النتائج؟

ميزة B-Tree أنها تحافظ على القيم مرتبة (Sorted). هذا يعطيها خصائص قوية:

الاستعلامات مثل:
WHERE age >= 20 AND age <= 30
يمكن تنفيذها بسهولة بفضل ترتيب القيم.
يمكن استخدام الفهرس لتسريع ORDER BY لأن البيانات مفهرسة بالفعل بترتيب معين.
يمكن تنفيذ عمليات Range Scan (مسح نطاق من القيم) بكفاءة عالية.

لذلك، فهارس B-Tree مناسبة جداً للاستعلامات التي تعتمد على:

المقارنة (>, <, >=, <=, BETWEEN)
الترتيب ORDER BY
LIMIT مع ORDER BY

فهرس مركّب (Composite Index) مع B-Tree

يمكنك إنشاء فهرس واحد يحتوي على أكثر من عمود، مثلاً:

INDEX (country, city)

في هذه الحالة، B-Tree ترتّب القيم أولاً حسب country، وداخل نفس الدولة ترتّب حسب city.

هذا يجعل الاستعلامات مثل:

WHERE country = 'EG' AND city = 'Cairo'
WHERE country = 'EG'

يتم تنفيذها بكفاءة كبيرة باستخدام نفس الفهرس. لكن:

الاستعلام WHERE city = 'Cairo' وحده لا يستفيد بكفاءة كاملة من الفهرس (إلا في حالات معيّنة)، لأن الترتيب الأساسي هو على country.

فهم هذا الترتيب من أهم مهارات استخدام Database Indexing BTree بشكل صحيح.

Hash Index: السرعة مقابل المرونة

النوع الثاني الشائع هو Hash Index، ويُستخدم في بعض محركات قواعد البيانات أو أنواع جداول معيّنة، أو في قواعد بيانات NoSQL مثل Redis وغيرها.

ما هي فكرة Hash Index؟

فكرة التجزئة Hashing أن تأخذ قيمة (مثل email) وتُمررها على دالة Hash Function تعطيك رقماً (Hash Value). هذا الرقم يُستخدم كعنوان أو مفتاح في جدول تجزئة Hash Table.

يحتوي Hash Index على:

قيمة hash(email)
ومؤشر الصف في الجدول.

عند البحث عن email = '[email protected]':

تحسب قاعدة البيانات نفس الدالة: h = hash('[email protected]').
تذهب مباشرة إلى المكان h في جدول التجزئة.
تجد المؤشر للصف المطلوب (مع بعض المعالجات في حال تعارض القيم Collisions).

متى يكون Hash Index أسرع من B-Tree؟

في حالات البحث بالمساواة فقط:

WHERE email = '[email protected]'
WHERE id = 123

هنا Hash Index غالباً يكون:

أسرع في البحث (شبه وقت ثابت O(1) في المتوسط).
أبسط من ناحية الحسابات.

لكن هذا يأتي مع قيود مهمة جداً.

عيوب Hash Index مقارنة بـ B-Tree

لا يدعم الاستعلامات النطاقية:
لا يمكنك استخدامه بكفاءة مع:
- WHERE age >= 20 AND age <= 30
- ORDER BY age
لأنه لا يحتفظ بترتيب القيم، بل فقط بقيمة التجزئة.
لا يساعد في الفرز ORDER BY لأن المفاتيح مرتبة حسب hash(value) وليس حسب value نفسها.
قد يواجه مشاكل تعارض (Collisions) تتطلب آليات إضافية لحلها، مما يؤثر على الأداء.

لذلك Hash Index مناسب في سيناريوهات معيّنة جداً، وبشرط أن نوع الاستعلامات معروف وواضح (عادةً مساواة Exact Match فقط).

متى أستخدم B-Tree ومتى أستخدم Hash Index؟

استخدامات B-Tree Index

معظم الحالات العامة في قواعد البيانات العلائقية.
الاستعلامات التي تحتوي على:
- >, <, BETWEEN, BETWEEN AND
- ORDER BY, GROUP BY
- LIMIT مع ترتيب.
فهرسة الأعمدة التي تُستخدم في JOIN.
فهرسة الأعمدة المركّبة Composite Index.

استخدامات Hash Index

الاستعلامات من نوع مساواة فقط:
WHERE key = value
في أنظمة أو محركات تدعم هذا النوع بشكل خاص (مثل بعض جداول MySQL القديمة مثل MEMORY، أو أنظمة NoSQL).
عندما يكون حجم البيانات كبيراً جداً وعدد الاستعلامات بالمساواة ضخم، وتريد أفضل أداء ممكن في هذه الحالة تحديداً.

في الواقع، في كثير من قواعد البيانات الشائعة، لن تحتاج للتعامل مباشرة مع Hash Index، لأن المحرّك يختار الأنسب أو يعتمد غالباً على B-Tree كأساس.

كيف تؤثر الفهارس على عمليات INSERT وUPDATE وDELETE؟

التركيز غالباً يكون على تسريع SELECT، لكن الفهارس لها ثمن يجب فهمه.

كل فهرس إضافي يعني أن قاعدة البيانات يجب أن:
- تُحدّث الفهرس عند INSERT صف جديد.
- تُعدّل الفهرس عند UPDATE العمود المفهرس.
- تحذف من الفهرس عند DELETE الصف.
هذا يزيد:
- زمن تنفيذ عمليات الكتابة (Write Operations).
- استهلاك المساحة على القرص.

الهدف ليس أن "تفهرس كل شيء"، بل أن تفهرس ما تحتاجه فقط بناءً على الاستعلامات الحقيقية في التطبيق.

أهم الأخطاء الشائعة عند استخدام الفهارس

الكثير من المطورين يعرفون إنشاء الفهرس بأمر بسيط، لكن استخدامه بشكل خاطئ يحوّل Database Indexing BTree من أداة تحسين إلى سبب لتدهور الأداء.

1- إنشاء فهارس كثيرة بدون تحليل الاستعلامات

إضافة فهرس لكل عمود تقريباً خطأ شائع جداً:

ترتفع تكلفة INSERT/UPDATE/DELETE.
تزداد مساحة التخزين بشكل غير ضروري.
قد يختار Optimizer فهرساً غير مناسب في بعض الحالات.

الحل:

استخدم أدوات مثل EXPLAIN أو EXPLAIN ANALYZE لمعرفة الاستعلامات البطيئة وكيفية تنفيذها.
قم بفهرسة الأعمدة المستخدمة بشكل متكرر في WHERE, JOIN, ORDER BY فقط.

2- استخدام دوال على الأعمدة المفهرسة في WHERE

مثال:

WHERE DATE(created_at) = '2024-01-01'

حتى لو كان لديك فهرس على created_at، استخدام دالة DATE() يمنع قاعدة البيانات غالباً من الاستفادة من الفهرس (أو يحدّ من فائدته).

الأفضل:

WHERE created_at >= '2024-01-01 00:00:00' AND created_at < '2024-01-02 00:00:00'

بهذه الطريقة يمكن لـ B-Tree استخدام الفهرس في بحث نطاقي Range Scan.

3- تجاهل ترتيب الأعمدة في الفهرس المركّب

إنشاء فهرس مركّب (country, city, age) لا يعني أن كل استعلام يستخدم أي ترتيب لهذه الأعمدة سيستفيد منه.

B-Tree تقرأ بهذا الترتيب:

ترتيب حسب country.
داخل نفس الدولة، ترتيب حسب city.
داخل نفس المدينة، ترتيب حسب age.

لذلك:

WHERE country = 'EG' AND city = 'Cairo' ⇒ ممتاز لهذا الفهرس.
WHERE city = 'Cairo' AND age > 20 ⇒ لن يستفيد بالكامل من هذا الفهرس.

رتّب الأعمدة في الفهرس المركّب بحسب:

الأعمدة الأكثر استخداماً في WHERE في البداية.
ثم الأعمدة المستخدمة في الفرز ORDER BY أو النطاق.

4- الاعتماد على LIKE مع بادئة % على أعمدة مفهرسة

استعلام مثل:

WHERE name LIKE '%ali'

في العادة لا يمكن تنفيذه بكفاءة باستخدام B-Tree لأن البادئة غير معروفة (% في البداية)، فيضطر المحرك لمسح نطاق كبير جداً أو عمل Full Table Scan.

الأفضل (إن أمكن):

WHERE name LIKE 'ali%' ⇒ يمكن استخدام الفهرس لأن البداية معروفة.
أو استخدام تقنيات بحث نصي كامل (Full Text Search) مخصصة.

5- الاعتقاد أن ORM سيتكفّل بكل شيء

الكثير من المطورين الذين يعملون بأطر مثل Django أو Laravel يظنون أن ORM سيُنشئ الفهارس المثالية تلقائياً. ORM عادة:

يُنشئ فهرساً للمفتاح الأساسي (Primary Key).
قد ينشئ فهارس لبعض العلاقات Foreign Keys.

لكن غالباً لن يقوم بفهرسة أعمدة الاستعلامات المعقّدة التي تكتبها أنت. لذلك من المهم:

مراجعة الاستعلامات الثقيلة.
إنشاء الفهارس يدوياً أو عبر Migration كما نوضح في مقال: تحسين استعلامات Django ORM لأداء أعلى

نصائح عملية لاستخدام Database Indexing BTree بذكاء

ابدأ بتحليل الاستعلامات البطيئة فقط، لا تفهرس بشكل عشوائي.
افهم طبيعة استعلاماتك:
- هل تعتمد على مساواة فقط؟
- أم على نطاقات وترتيب؟
استخدم B-Tree كخيار افتراضي لأنه الأكثر مرونة ودعماً من المحركات.
فكّر في Hash Index فقط عندما:
- يكون المحرّك يدعمه.
- وتكون الاستعلامات مساواة فقط.
راقب دائماً تأثير الفهارس على عمليات الإدخال والتحديث والحذف.

خلاصة

الفهارس هي واحدة من أقوى أدوات تحسين الأداء في قواعد البيانات، لكن فهم كيفية عملها – خاصة Database Indexing BTree وأنواع أخرى مثل Hash Index – هو ما يميّز بين نظام سريع ومستقر، وآخر يعاني من بطء مزمن.

باختصار:

B-Tree:
- مرن جداً.
- يدعم المساواة، والنطاق، والفرز.
- الاختيار الافتراضي في معظم الحالات.
Hash Index:
- أسرع في المساواة فقط.
- لا يدعم النطاق والفرز.
- مناسب لحالات خاصة جداً.

استخدام الفهارس بشكل صحيح يتطلّب:

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

بهذا تكون قد حصلت على صورة واضحة عن كيفية عمل الفهارس في قواعد البيانات، وكيف تختار بين B-Tree وHash Index، وكيف تتجنّب الأخطاء التي قد تدمّر الأداء بدلاً من تحسينه.