الفهارس في SQLite: CREATE INDEX ومتى تستخدمها

ما هو الفهرس فعلياً؟

الفهرس (Index) هو هيكل بيانات منفصل — عبارة عن شجرة B-tree مرتّبة — يتيح لـ SQLite العثور على الصفوف بناءً على قيمة عمود معيّن دون الحاجة إلى مسح الجدول بالكامل. بدون فهرس، فإن استعلاماً مثل WHERE email = 'rosa@example.com' يقرأ كل صف ويتحقّق منه واحداً تلو الآخر. أمّا مع وجود فهرس على عمود email، فإن SQLite يجتاز الشجرة في عدد خطوات يقارب log(n) ويصل مباشرة إلى النتيجة المطلوبة.

لكن هذا التسريع لا يأتي مجاناً. فالفهرس في حقيقته نسخة من العمود المُفهرَس مع مؤشّر يشير إلى الصف الأصلي. وهذا يعني أن كل عملية INSERT، وكل UPDATE يطال عموداً مُفهرَساً، وكل DELETE تستوجب تحديث الفهرس أيضاً. النتيجة: مساحة تخزين أكبر، وتراجع طفيف في سرعة الكتابة. الصفقة باختصار: تدفع قليلاً عند الكتابة، وتربح الكثير عند القراءة.

إنشاء فهرس باستخدام CREATE INDEX في SQLite

الصيغة الأساسية كالتالي:

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email TEXT NOT NULL,
    name TEXT,
    created_at TEXT
);

INSERT INTO users (email, name, created_at) VALUES
    ('rosa@example.com', 'Rosa', '2026-01-10'),
    ('boris@example.com', 'Boris', '2026-02-14'),
    ('ada@example.com', 'Ada', '2026-03-01');

CREATE INDEX idx_users_email ON users(email);

SELECT * FROM users WHERE email = 'boris@example.com';

اصطلاح التسمية: معظم الفِرَق تتبع النمط idx_<table>_<column> حتى يتضح الغرض من الفهرس بمجرد النظر إليه. لاحظ أن الاسم يجب أن يكون فريدًا على مستوى قاعدة البيانات بأكملها، لا على مستوى الجدول فقط، ولهذا السبب نُضمّن اسم الجدول داخل الاسم.

ولحذف الفهرس:

DROP INDEX idx_users_email;

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

الفهرس الفريد UNIQUE INDEX في SQLite

الفهرس الفريد يؤدي وظيفتين في آنٍ واحد: يُسرّع عمليات البحث ويضمن في الوقت نفسه ألّا يتكرر نفس القيمة في صفّين مختلفين.

CREATE TABLE accounts (
    id INTEGER PRIMARY KEY,
    username TEXT NOT NULL
);

CREATE UNIQUE INDEX idx_accounts_username ON accounts(username);

INSERT INTO accounts (username) VALUES ('rosa');
INSERT INTO accounts (username) VALUES ('boris');
INSERT INTO accounts (username) VALUES ('rosa');

يفشل الإدراج الثالث برسالة UNIQUE constraint failed: accounts.username. فـ SQLite ينشئ فهارس فريدة تلقائيًا لأعمدة PRIMARY KEY وUNIQUE، وستجدها بأسماء على شاكلة sqlite_autoindex_<table>_<n>. لذلك لا تحتاج إلى كتابة CREATE UNIQUE INDEX يدويًا إلا حين لا يكون القيد معرَّفًا أصلًا على الجدول.

ماذا يفعل مخطِّط الاستعلامات فعليًا؟

إنشاء الفهرس وحده لا يضمن أن يستخدمه SQLite. فمخطِّط الاستعلامات (Query Planner) يختار خطة تنفيذ مستقلة لكل استعلام، ويمكنك معاينة ما اختاره عبر EXPLAIN QUERY PLAN:

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

INSERT INTO orders (customer_id, total, status) VALUES
    (1, 99.0, 'shipped'), (2, 45.5, 'pending'),
    (1, 12.0, 'shipped'), (3, 200.0, 'pending');

CREATE INDEX idx_orders_customer ON orders(customer_id);

EXPLAIN QUERY PLAN
SELECT * FROM orders WHERE customer_id = 1;

ابحث في الناتج عن SEARCH ... USING INDEX idx_orders_customer — وجوده يعني أن الفهرس مُستخدَم فعلًا. أما إذا ظهر لك SCAN orders، فهذا يعني أن مُخطِّط الاستعلام رأى أن المسح الكامل للجدول أرخص (وهذا صحيح غالبًا مع الجداول الصغيرة)، أو أن صياغة استعلامك منعته من استغلال الفهرس. وسنُفرد لاحقًا مقالًا كاملًا لقراءة هذه الخطط بالتفصيل.

متى لا يستفيد SQLite من الفهرس؟

للفهارس بعض النقاط العمياء المعروفة، وكل حالة من الحالات التالية كفيلة بتعطيل الفهرس المُنشأ على عمود email:

-- الدالة تُغلِّف العمود
SELECT * FROM users WHERE lower(email) = 'rosa@example.com';

-- حرف بدل في بداية LIKE
SELECT * FROM users WHERE email LIKE '%@example.com';

-- عدم تطابق النوع يفرض تحويلاً
SELECT * FROM users WHERE email = 12345;

شجرة B-tree مرتّبة وفق قيمة email الخام، لذا أي تحويل تُجريه على العمود وقت الاستعلام سيُجبر المحرّك على مسح الجدول بالكامل. الحلول متعدّدة: خزّن البيانات مُطبَّعة مسبقًا في عمود مستقل مثل email_lower، أو استخدم فهرسًا على تعبير بهذا الشكل CREATE INDEX idx ON users(lower(email))، أو اعتمد على البحث النصّي الكامل (FTS) في SQLite عند الحاجة لمطابقة جزء من النص.

الفهارس المُغطِّية (Covering Index في SQLite)

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

CREATE TABLE events (
    id INTEGER PRIMARY KEY,
    user_id INTEGER,
    type TEXT,
    created_at TEXT
);

INSERT INTO events (user_id, type, created_at) VALUES
    (1, 'login', '2026-01-01'),
    (1, 'click', '2026-01-02'),
    (2, 'login', '2026-01-03');

CREATE INDEX idx_events_user_type ON events(user_id, type);

EXPLAIN QUERY PLAN
SELECT user_id, type FROM events WHERE user_id = 1;

بما أن العمودين المطلوبين في الاستعلام موجودان داخل الفهرس نفسه، يُبلِّغ SQLite بـ USING COVERING INDEX، دون الحاجة لجلب الصف الأصلي. الـ covering index من أقوى أساليب تحسين أداء استعلامات SQLite في مسارات القراءة الساخنة — والمقابل طبعًا هو فهرس أكبر حجمًا. أما الفهارس متعددة الأعمدة فلها حديث مستقل، وسنتناولها بالتفصيل في الدرس القادم.

عرض الفهارس وفحصها

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

CREATE TABLE products (
    id INTEGER PRIMARY KEY,
    sku TEXT UNIQUE,
    name TEXT
);

CREATE INDEX idx_products_name ON products(name);

SELECT name, tbl_name, sql FROM sqlite_master WHERE type = 'index';

هذا الاستعلام يعرض لك كل الفهارس الموجودة في قاعدة البيانات مع جملة CREATE الخاصة بكل واحد منها. ولو أردت الاطلاع على فهارس جدول واحد فقط، استخدم PRAGMA index_list('products'); لعرض فهارس هذا الجدول، ثم PRAGMA index_info('idx_products_name'); لمعرفة الأعمدة التي يغطيها كل فهرس. أي فهرس يبدأ اسمه بـ sqlite_autoindex_ فهو فهرس أنشأته SQLite تلقائيًا لخدمة قيد PRIMARY KEY أو UNIQUE، ولا يمكن حذفه.

متى لا يجب إضافة فهرس في SQLite

هناك حالات تجعل إضافة الفهرس تضرّ أكثر مما تنفع:

• الجداول الصغيرة جدًا. بضع مئات من الصفوف يمسحها المحرك في أجزاء من الميكروثانية. غالبًا ما يتجاهل مخطط الاستعلامات الفهرس أصلًا، وتكون قد أضفت عبئًا على عمليات الكتابة دون أي فائدة.
• الأعمدة كثيرة الكتابة ونادرة الاستعلام. كل عملية كتابة تُحدِّث كل فهرس. إذا فهرست عمودًا لا تكاد تُرشِّح به، فأنت تدفع التكلفة بلا مقابل.
• الأعمدة منخفضة التنوّع بمفردها. فهرس على عمود status فيه ثلاث قيم محتملة لن يُضيِّق نطاق البحث كثيرًا. قد يفيد كعمود ثانٍ ضمن فهرس مركّب، أو كفهرس جزئي، لكنه بمفرده لا يستحق العناء في الغالب.
• مغطّى مسبقًا. إذا كان عندك فهرس على (a, b) فلست بحاجة إلى فهرس آخر على (a) وحده. فـ SQLite يستخدم الأعمدة الأولى من الفهرس المركّب للاستعلامات التي ترشّح بـ a فقط.

الجواب الصادق على سؤال "هل أضيف هذا الفهرس؟" يكون دائمًا تقريبًا: جرّبه، شغّل EXPLAIN QUERY PLAN، اقِس الأداء ببيانات واقعية، ثم اتخذ القرار.

بعد ذلك: الفهارس المركّبة

الفهرس على عمود واحد يغطي كثيرًا من الحالات، لكن الاستعلامات الحقيقية كثيرًا ما تُرشِّح وتُرتِّب على عدة أعمدة في آنٍ واحد. هنا يأتي دور الفهارس المركّبة — أي الفهارس على (a, b, c) — وترتيب الأعمدة فيها أهم بكثير مما يتوقع الناس. وهذا موضوع الصفحة التالية.