İndeks (Veritabanı)

Veritabanı indeksi, bir tablonun bir veya daha fazla sütunu üzerine inşa edilen, tipik olarak bir B-tree veya benzeri sıralı bir yapı olan, bu sütunlar üzerindeki aramaları her satırı taramaktan çarpıcı şekilde daha hızlı hale getiren yardımcı bir veri yapısıdır. İndeks olmadan, belirli bir satırı bulmak (`WHERE email = 'user@example.com'`), veritabanının tablodaki her tek satırı kontrol etmesini gerektirir ("sıralı tarama" veya "tablo taraması") - birkaç yüz satır için iyidir, birkaç milyon satır için yıkıcıdır. AI/SaaS kurucuları için neden önemli: indeksleme, mevcut en yüksek etkili, en düşük çabalı performans müdahalelerinden biridir ve yokluğu, klasik "büyüdükçe uygulama yavaşladı" şikayetinin başlıca nedenidir. Bir vektör veritabanının embedding'ler üzerine inşa ettiği "indeks"ten (embedding indeksi) farklıdır - ama kavramsal olarak ilişkilidir: her ikisi de daha hızlı okumalar için yazma yükü ve ekstra depolamayı takas eder, yalnızca çok farklı veri türleri üzerinde ve çok farklı temel yapılar kullanarak (skaler değerler üzerinde tam/aralık eşleşmeleri için B-tree'ler, yüksek boyutlu vektörler üzerinde yaklaşık benzerlik için HNSW/IVFFlat). Nasıl çalışır: tipik bir B-tree indeksi, sütun değerlerini tam satıra geri işaret eden bir gösterge ile birlikte sıralı düzende tutar; böylece veritabanı doğrusal taramak yerine eşleşen değere ikili arama yapabilir - O(n) bir aramayı kabaca O(log n)'ye dönüştürür. İndeksler, `WHERE` cümlelerinde, `JOIN` koşullarında ve `ORDER BY` cümlelerinde sık kullanılan sütunlara eklenmelidir - ama gelişigüzel değil, çünkü her indeks her `INSERT`/`UPDATE`/`DELETE`'e ek yük getirir (indeksin kendisi de güncellenmelidir) ve ek disk alanı tüketir; yazma yoğun bir tabloyu aşırı indekslemek gerçek ve yaygın bir hatadır. Bileşik indeksler (birden fazla sütuna yayılan, örneğin `(customer_id, created_at)`), tam olarak o kombinasyonu filtreleyen veya sıralayan sorguları hızlandırır ama B-tree sıralamasının işleyişi nedeniyle yalnızca ikinci sütuna dokunan sorgular için daha az kullanışlıdır - bu, çok sayıda sorgu optimizasyonu çalışmasını tökezleten ince bir noktadır. Somut örnek: çok kiracılı bir SaaS'ın `events` tablosu 40 milyon satıra büyür; `WHERE customer_id = ? AND created_at > ?` filtreleyen bir gösterge paneli sorgusu, sıralı bir tarama olarak 6+ saniye sürmeye başlar. Bileşik bir indeks eklemek `CREATE INDEX idx_events_customer_created ON events (customer_id, created_at);` aynı sorguyu 10 milisaniyenin altına düşürür, çünkü Postgres artık her gösterge paneli yüklemesinde tüm tabloyu okumak yerine doğrudan o müşteri ve zaman aralığı için ilgili satırlara atlayabilir. Ekip ayrıca, sorgu planlayıcısının yoksaymak yerine gerçekten yeni indeksi kullanmayı seçtiğini doğrulamak için sorgudan önce ve sonra `EXPLAIN ANALYZE` çalıştırır - bu, normalleştirilmeye değer bir adımdır, çünkü var olan ama kullanılmayan bir indeks (bir bileşik indeksteki kötü sütun sıralamasının yaygın bir sonucu) tam yazma zamanı maliyetini ödemeye devam ederken sıfır fayda sağlar.