SQLite Composite Index: Sütun Sırası ve Soldan Önek Kuralı

Tek Index, Birden Fazla Sütun

Composite index — yani çok sütunlu index — iki ya da daha fazla sütun üzerine kurulan tek bir index'tir. Oluştururken sütunları sırayla yazmanız yeterli:

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 indexi, kayıtları önce customer_id'ye, ardından her müşteri içinde status'a göre sıralı tutar. Bu sıralama meselenin tamamı — composite index'lerle ilgili geri kalan her şey buradan türüyor.

Zihinsel Model: Sıralı Bir Telefon Rehberi

Eski tarz bir telefon rehberi düşün. Kayıtlar önce soyada göre, aynı soyad içinde ise ada göre sıralı. (last_name, first_name) üzerindeki bir index aynen böyle görünür.

Bazı sorgular ucuza gelir, bazıları gelmez:

• "Soyadı Patel olan herkesi bul" — kolay, tüm Patel'ler yan yana.
• "Priya Patel'i bul" — kolay, Patel'e atla, sonra Priya'ya kadar tara.
• "Adı Priya olan herkesi bul" — yavaş, her sayfayı baştan sona taramanız gerekir. Priya'lar her soyadın altına dağılmış durumda.

SQLite'taki çok sütunlu bir index de tam olarak böyle çalışır. İlk sütun birincil sıralama anahtarıdır; ikinci sütun yalnızca ilk sütun değeri aynı olan kayıtları kendi içinde sıralar.

Leftmost Prefix Kuralı

SQLite, bir composite index'i ancak WHERE koşulu o index'in sütunlarının en soldaki bir önekini (leftmost prefix) kısıtlıyorsa kullanabilir. (a, b, c) üzerindeki bir index için:

• Sadece a ile filtreleme — index kullanılır.
• a ve b ile filtreleme — index kullanılır.
• a, b ve c ile filtreleme — index kullanılır.
• Tek başına b, tek başına c ya da b ve c ile filtreleme — index kullanılmaz.

Bunu doğrudan EXPLAIN QUERY PLAN ile doğrulayabilirsiniz:

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';

İlk planda SEARCH events USING INDEX idx_events_user_kind_time görüyoruz. İkincisi ise SCAN events'e düşüyor — sadece kind üzerinden filtrelemek baştaki user_id sütununu atladığı için index bu sorguda işe yaramıyor.

Sütun Sırası Bir Tasarım Kararıdır

Leftmost prefix kuralı devreye girdiğinden, CREATE INDEX içinde sütunları hangi sırayla yazdığınız stilistik bir tercih değil, gerçek bir karardır. İki pratik kural:

1. En sık filtrelediğiniz sütunu başa koyun. O sütun, index'i en geniş sorgu yelpazesine açar.
2. Eşitlik (equality) sütunlarını aralık (range) sütunlarından önce yazın. SQLite önce = ile index'in derinine inip ardından <, > veya BETWEEN ile bitişik bir aralığı tarayabilir — ama bunu yalnızca kullanılan son sütunda yapabilir.

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

-- İyi: önce region üzerinde eşitlik, sonra sold_at üzerinde aralık.
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';

Plan çıktısında şunu görüyorsunuz: SEARCH sales USING INDEX idx_sales_region_time (region=? AND sold_at>?). SQLite doğrudan region = 'EU' satırlarına atlıyor, ardından tarih aralığı boyunca ileri doğru ilerliyor. Sütun sırasını (sold_at, region) şeklinde değiştirdiğinde ise aynı sorgu, tarih aralığındaki tüm satırları taramak ve her biri için region değerini tekrar kontrol etmek zorunda kalıyor.

Composite Index mi, Birden Fazla Tek Sütunlu Index mi?

Sıkça karşılaşılan bir soru: (a, b) üzerinde tek bir index mi oluşturmalıyım, yoksa a ve b için ayrı ayrı iki index mi?

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

-- Seçenek A: tek bir bileşik indeks.
CREATE INDEX idx_tickets_proj_state ON tickets(project_id, state);

-- Seçenek B (alternatif): iki tek sütunlu indeks.
-- 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';

Birleşik filtrede composite index açık ara daha hızlıdır — SQLite eşleşen (project_id, state) kayıtlarına doğrudan gider. İki ayrı tek sütunlu index olduğunda ise SQLite genelde birini seçip satırları daraltır, sonra eşleşen her satırda diğer sütunu yeniden kontrol eder. Bazen iki index'i kesişim yoluyla kullanabilir, ancak iki sütun birlikte sorgulandığında çok sütunlu index (composite index) çok daha temiz bir çözümdür.

project_id ve state ayrı ayrı da sorgulanıyorsa ikisini birden tutmak isteyebilirsiniz: birleşik filtre için composite index, sadece state üzerinden filtre uygulayan sorgular için de tek sütunlu bir index.

Covering Index (Kapsayıcı Index)

Bir index, sorgunun ihtiyaç duyduğu tüm sütunları — hem filtre sütunlarını hem de seçilen sütunları — içeriyorsa SQLite yanıtı tabloya hiç dokunmadan üretebilir. Buna covering index denir ve bir sorgunun ulaşabileceği en yüksek hız budur.

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, 'ilk'),
    (1, '2026-02-02', 250, NULL),
    (2, '2026-01-30',  75, 'acil');

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

Planda USING COVERING INDEX idx_invoices_cover ifadesini görüyorsunuz. Sorgu issued_at ve total değerlerini doğrudan index'ten okuyor; notes ve id gerekmediği için tabloya hiç dokunulmuyor. Sürekli çalışan bir sorguyu komple karşılayabilmek adına composite index'e fazladan bir sütun eklemek, bu tarz durumlarda kesinlikle değer.

Composite UNIQUE Kısıtlamaları

SQLite composite index'leri, sütun kombinasyonları üzerinde benzersizliği zorlamak için de kullanılır. Tek başına hiçbir sütunun unique olmadığı, ama kombinasyonun unique olması gereken senaryolarda işe yarar:

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');  -- tamam, farklı ders
INSERT INTO enrollments VALUES (1, 100, '2026-02-01');  -- başarısız: çift tekrar ediyor

Üçüncü insert şu hatayı fırlatır: UNIQUE constraint failed: enrollments.student_id, enrollments.course_id. Aynı çift zaten index'te mevcut olduğu için SQLite mükerrer kaydı reddeder.

Dikkat Edilmesi Gereken Tuzaklar

• Baştaki olmayan sütunlar arasındaki OR index'i devre dışı bırakır. (a, b) index'i üzerinde WHERE a = 1 OR b = 2 sorgusu genellikle index'ten hiç faydalanamaz — SQLite iki dalı ayrı ayrı değerlendirmek zorunda kalır.
• Index'lenmiş sütunlar üzerindeki fonksiyonlar index'i etkisiz kılar. WHERE lower(email) = 'x' ifadesi email sütunundaki index'i kullanmaz. Bunun yerine ifadenin kendisini index'leyin ya da veriyi insert sırasında normalize edin.
• Index'ler bedava değildir. Her INSERT, (index'li sütunları etkileyen) UPDATE ve DELETE işleminde tüm index'ler güncellenir. Yazma yükü ağır bir tabloda üç tane composite index, yazma maliyetinin büyük kısmını yutabilir.
• Index'leri oluşturduktan sonra mutlaka ANALYZE çalıştırın. SQLite'ın sorgu planlayıcısı, aday index'ler arasında seçim yaparken ANALYZE ile toplanan istatistiklere bakar. Bu istatistikler yoksa, her zaman optimal olmayan sezgisel kurallara geri döner.

Pratik Bir İş Akışı

Yavaş bir sorguyu iyileştirirken döngü genellikle şöyle ilerler:

1. Sorgu üzerinde EXPLAIN QUERY PLAN çalıştırın ve SQLite'ın şu an ne yaptığını görün.

2. Tablo taraması yapıyorsa WHERE cümlesine bakın — eşitlik sütunu hangisi? Aralık (range) sütunu hangisi? Hangi sütunlar seçiliyor?

3. Önce eşitlik, sonra aralık olacak şekilde sıralanmış bir composite index kurun; covering index işe yarayacaksa seçilen sütunları da sona ekleyin.

4. ANALYZE çalıştırın.

5. EXPLAIN QUERY PLAN'ı tekrar çalıştırın. Planın değiştiğini ve index'in kullanıldığını doğrulayın.

6. Sorguyu, gerçeği temsil eden veriler üzerinde önce ve sonra olarak ölçün.

7. adımı atlarsanız sonuçlarına katlanırsınız. Planda doğru görünen bir index, tablo küçükse ya da planlayıcı farklı bir yol seçerse pratikte daha yavaş kalabilir.

Sırada: Partial Index'ler

Composite index'ler tablodaki her satırı kapsar. Ama çoğu zaman yalnızca küçük bir satır kümesi önemlidir — açık biletler, işlenmemiş işler, silinmemiş kayıtlar. Partial index, index'in kendisine gömülü bir WHERE cümlesiyle yalnızca o satırları index'lemenizi sağlar. Bir sonraki sayfanın konusu bu.