الفهارس المركبة في SQLite وقاعدة البادئة اليسرى

فهرس واحد يغطّي عدّة أعمدة

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

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer_id INTEGER NOT NULL,
    status TEXT NOT NULL,
    created_at TEXT NOT NULL,
    total REAL NOT NULL
);

CREATE INDEX idx_orders_customer_status
    ON orders(customer_id, status);

INSERT INTO orders(customer_id, status, created_at, total) VALUES
    (1, 'paid',    '2026-01-10', 49.00),
    (1, 'paid',    '2026-02-03', 12.50),
    (1, 'pending', '2026-02-14',  9.99),
    (2, 'paid',    '2026-01-22', 80.00),
    (2, 'refunded','2026-02-01', 25.00);

SELECT * FROM orders WHERE customer_id = 1 AND status = 'paid';

الفهرس idx_orders_customer_status يخزّن المُدخلات مرتّبةً أولًا حسب customer_id، ثم حسب status داخل كل عميل. هذا الترتيب هو جوهر الموضوع كله، وكل ما يخص الفهارس المركّبة في SQLite يتفرّع منه.

التصوّر الذهني: دفتر هاتف مُرتَّب

تخيّل دفتر هاتف قديم. الأسماء فيه مرتّبة حسب اسم العائلة، وداخل كل عائلة تكون مرتّبة حسب الاسم الأول. هذا بالضبط شكل أي فهرس على (last_name, first_name).

بعض عمليات البحث رخيصة، وبعضها مُكلف:

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

الفهرس المركّب في SQLite يعمل بنفس الأسلوب تمامًا. العمود الأول هو مفتاح الترتيب الرئيسي، والعمود الثاني لا يُرتَّب إلا بين المُدخلات التي تتشارك في نفس قيمة العمود الأول.

قاعدة البادئة اليسرى (Leftmost Prefix Rule)

لا يستطيع SQLite استخدام الفهرس المركّب لاستعلام ما إلا إذا كانت جملة WHERE تُقيّد بادئة يسرى من أعمدته. لنأخذ فهرسًا على (a, b, c):

• التصفية باستخدام a — يستخدم الفهرس.
• التصفية باستخدام a وb — يستخدم الفهرس.
• التصفية باستخدام a وb وc — يستخدم الفهرس.
• التصفية باستخدام b وحده، أو c وحده، أو b وc معًا — لن يستخدم الفهرس.

ويمكنك التحقّق من ذلك مباشرةً عبر EXPLAIN QUERY PLAN:

CREATE TABLE events (
    id INTEGER PRIMARY KEY,
    user_id INTEGER NOT NULL,
    kind TEXT NOT NULL,
    occurred_at TEXT NOT NULL
);

CREATE INDEX idx_events_user_kind_time
    ON events(user_id, kind, occurred_at);

EXPLAIN QUERY PLAN
SELECT * FROM events WHERE user_id = 42 AND kind = 'login';

EXPLAIN QUERY PLAN
SELECT * FROM events WHERE kind = 'login';

الخطة الأولى تُظهر SEARCH events USING INDEX idx_events_user_kind_time، بينما تتراجع الخطة الثانية إلى SCAN events — لأن التصفية على kind وحده يتخطى العمود الأول user_id، فيصبح الفهرس عديم الفائدة لهذا الاستعلام.

ترتيب الأعمدة في الفهرس قرار تصميمي

بما أن قاعدة البادئة اليسرى (leftmost prefix rule) هي الحاكمة، فإن ترتيب الأعمدة الذي تكتبه داخل CREATE INDEX خيار حقيقي، لا مجرد مسألة شكلية. إليك قاعدتين عمليتين:

1. ابدأ بالعمود الذي تُصفّي به أكثر من غيره. هذا العمود هو الذي يفتح الفهرس أمام أوسع قدر ممكن من الاستعلامات.
2. ضع أعمدة المساواة قبل أعمدة النطاق. يستطيع SQLite الوصول المباشر داخل الفهرس عبر =، ثم يمسح نطاقًا متصلًا باستخدام < أو > أو BETWEEN — لكن فقط على آخر عمود مُستخدَم.

CREATE TABLE sales (
    id INTEGER PRIMARY KEY,
    region TEXT NOT NULL,
    sold_at TEXT NOT NULL,
    amount REAL NOT NULL
);

-- جيد: المساواة على region أولاً، والنطاق على sold_at ثانياً.
CREATE INDEX idx_sales_region_time ON sales(region, sold_at);

INSERT INTO sales(region, sold_at, amount) VALUES
    ('EU', '2026-01-05', 120),
    ('EU', '2026-02-11', 80),
    ('US', '2026-01-09', 200),
    ('US', '2026-02-20', 150);

EXPLAIN QUERY PLAN
SELECT * FROM sales
WHERE region = 'EU' AND sold_at >= '2026-02-01';

تُظهر الخطة SEARCH sales USING INDEX idx_sales_region_time (region=? AND sold_at>?). هنا ينتقل SQLite مباشرة إلى region = 'EU'، ثم يتقدّم عبر النطاق الزمني. لكن لو عكست ترتيب الأعمدة إلى (sold_at, region)، فسيضطر نفس الاستعلام إلى المرور على كل صف ضمن النطاق الزمني وإعادة فحص region في كل مرة.

الفهرس المركب مقابل عدة فهارس أحادية العمود

سؤال يتكرر كثيرًا: هل الأفضل إنشاء فهرس واحد على (a, b)، أم فهرسين منفصلين على a و b؟

CREATE TABLE tickets (
    id INTEGER PRIMARY KEY,
    project_id INTEGER NOT NULL,
    assignee_id INTEGER NOT NULL,
    state TEXT NOT NULL
);

-- الخيار أ: فهرس مركّب واحد.
CREATE INDEX idx_tickets_proj_state ON tickets(project_id, state);

-- الخيار ب (بديل): فهرسان أحاديا العمود.
-- CREATE INDEX idx_tickets_project ON tickets(project_id);
-- CREATE INDEX idx_tickets_state   ON tickets(state);

EXPLAIN QUERY PLAN
SELECT * FROM tickets
WHERE project_id = 7 AND state = 'open';

بالنسبة للاستعلام المركب الذي يجمع شرطين، يتفوق الفهرس المركب في السرعة — إذ ينتقل SQLite مباشرة إلى السجلات المطابقة لقيم (project_id, state). أما عند استخدام فهرسين منفصلين لكل عمود، فإن SQLite يختار عادةً أحدهما لتضييق نطاق النتائج، ثم يتحقق من العمود الآخر يدويًا في كل صف ناتج. صحيح أنه قد يلجأ أحيانًا إلى تقاطع الفهرسين، لكن يبقى الفهرس المركب هو الحل الأنظف حين تُستعلم الأعمدة مجتمعةً.

أما إذا كنت تستعلم عن project_id و state كلٌّ على حدة أيضًا، فقد تحتاج إلى الاثنين معًا: الفهرس المركب للاستعلامات المشتركة، وفهرس مفرد على state للاستعلامات التي تعتمد عليه وحده.

الفهرس المغطي (Covering Index) في SQLite

عندما يحتوي الفهرس على جميع الأعمدة التي يطلبها الاستعلام — سواء أعمدة التصفية أو الأعمدة المُختارة في SELECT — يستطيع SQLite الإجابة دون الرجوع إلى الجدول الأصلي إطلاقًا. هذا ما يُعرف بـ covering index، وهو أسرع شكل يمكن أن يصل إليه الاستعلام.

CREATE TABLE invoices (
    id INTEGER PRIMARY KEY,
    customer_id INTEGER NOT NULL,
    issued_at TEXT NOT NULL,
    total REAL NOT NULL,
    notes TEXT
);

CREATE INDEX idx_invoices_cover
    ON invoices(customer_id, issued_at, total);

INSERT INTO invoices(customer_id, issued_at, total, notes) VALUES
    (1, '2026-01-12', 100, 'الأولى'),
    (1, '2026-02-02', 250, NULL),
    (2, '2026-01-30',  75, 'عاجلة');

EXPLAIN QUERY PLAN
SELECT issued_at, total FROM invoices WHERE customer_id = 1;

الخطة تُظهر USING COVERING INDEX idx_invoices_cover. الاستعلام يقرأ issued_at و total مباشرةً من الفهرس — أمّا notes و id فلا حاجة إليهما، ولذلك لا يُفتح الجدول الأصلي إطلاقًا. إضافة عمود إلى فهرس مركّب لمجرّد تغطية استعلام كثير الاستخدام صفقة مربحة عندما يكون هذا الاستعلام يعمل باستمرار.

قيود التفرّد المركّبة (Composite UNIQUE)

الفهرس المركّب في SQLite يصلح أيضًا لفرض التفرّد على مجموعة أعمدة مجتمعة. هذا مفيد حين لا يكون أيّ عمود بمفرده فريدًا، لكن المطلوب أن يكون الجمع بينها فريدًا:

CREATE TABLE enrollments (
    student_id INTEGER NOT NULL,
    course_id  INTEGER NOT NULL,
    enrolled_at TEXT NOT NULL
);

CREATE UNIQUE INDEX idx_enrollments_pair
    ON enrollments(student_id, course_id);

INSERT INTO enrollments VALUES (1, 100, '2026-01-05');
INSERT INTO enrollments VALUES (1, 101, '2026-01-05');  -- حسنًا، مقرر مختلف
INSERT INTO enrollments VALUES (1, 100, '2026-02-01');  -- يفشل: الزوج مكرر

عملية الإدخال الثالثة سترفع الخطأ UNIQUE constraint failed: enrollments.student_id, enrollments.course_id، لأن نفس الزوج موجود مسبقًا في الفهرس، فترفض SQLite تكرار القيمة.

مزالق ينبغي الانتباه إليها

• استخدام OR بين أعمدة ليست في المقدمة يُعطّل الفهرس. الشرط WHERE a = 1 OR b = 2 على فهرس (a, b) لا يستطيع غالبًا الاستفادة من الفهرس إطلاقًا، لأن SQLite مضطرة لمعالجة كل فرع على حدة.
• استدعاء الدوال على الأعمدة المفهرسة يُعطّل الفهرس. الشرط WHERE lower(email) = 'x' لن يستفيد من فهرس على العمود email. الحل أن تفهرس التعبير ذاته، أو أن تُطبّع البيانات لحظة الإدخال.
• الفهارس ليست مجانية. كل فهرس يُحدَّث مع كل عملية INSERT، ومع كل UPDATE تمسّ أعمدة مفهرسة، ومع كل DELETE. ثلاثة فهارس مركّبة على جدول كثير الكتابة قد تستهلك معظم تكلفة الكتابة.
• شغّل ANALYZE بعد بناء الفهارس. يعتمد مخطّط الاستعلامات في SQLite على الإحصاءات التي يجمعها ANALYZE للموازنة بين الفهارس المرشّحة. وبدون هذه الإحصاءات يلجأ إلى تقديرات تقريبية ليست دائمًا الأمثل.

سير عمل عملي

عند ضبط استعلام بطيء، تكون الدورة المعتادة كالتالي:

1. شغّل EXPLAIN QUERY PLAN على الاستعلام لترى ماذا تفعل SQLite حاليًا.
2. إذا كانت تُجري مسحًا كاملًا، تأمّل عبارة WHERE: ما العمود ذو شرط المساواة؟ وما العمود ذو شرط النطاق؟ وما الأعمدة المختارة في SELECT؟
3. ابنِ فهرسًا مركّبًا مرتّبًا بحيث تأتي أعمدة المساواة أولًا ثم أعمدة النطاق، مع إلحاق الأعمدة المختارة إذا كان الفهرس المُغطّي (covering index) سيُفيد.
4. شغّل ANALYZE.
5. شغّل EXPLAIN QUERY PLAN مرة أخرى، وتحقّق من أن الخطة تغيّرت فعلًا وأن الفهرس قيد الاستخدام.
6. قِس زمن تنفيذ الاستعلام قبل التعديل وبعده، على بيانات تمثّل الواقع.

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

المحطة التالية: الفهارس الجزئية

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