Veritabanı indeksi, her kolona peşinen basılan bir süs değildir; yavaş liste ve filtre sorgusunun şekline göre seçilen bir erişim yoludur. Bu rehber, tarama ile aramayı ayırır, bileşik kolon sırasını somutlar ve kullanılmayan indeksi ne zaman bırakacağınızı netleştirir.
Liste sayfanız geç açılıyor, yönetim panelindeki sipariş filtresi bekletiyor veya aynı tablo her raporda baştan taranıyor olabilir. İlk refleks çoğu ekipte aynıdır: her kolona indeks eklemek. Yanlış yerdeki indeks okumayı hızlandırmaz; yazmayı ağırlaştırır ve planlayıcıyı şaşırtır.
Kısa cevap şudur: veritabanı indeksi nedir diye sorulduğunda, motorun satırları tek tek gezmeden WHERE, JOIN ve ORDER BY koşullarına ulaşmasını sağlayan yardımcı yapıdır. Asıl karar, hangi kolonun önemli göründüğü değil; hangi listenin ve filtrenin gerçekten yavaş olduğunun ölçülmesidir.
Bu rehber indeksi yalnızca tanımlamaz. Yavaş sorguyu nasıl yakalayacağınızı, kolonu nasıl seçeceğinizi, bileşik sırayı neden bozamayacağınızı ve kullanılmayan indeksi ne zaman sileceğinizi adım adım anlatır.
Veritabanı indeksi nedir ve ne işe yarar
Veritabanı indeksi, tablo satırlarının kopyası değildir. Değerleri düzenli tutan ve satırın yerini işaret eden ayrı bir yapıdır. Kitap sonundaki dizin gibidir: her sayfayı gezmezsiniz, maddeye bakıp sayfa numarasına gidersiniz.
Çoğu ilişkisel motorda varsayılan yapı, eşitlik ve aralık aramalarında işe yarayan ağaç benzeri bir indekstir. Birincil anahtar zaten bir indekstir; aynı kolona ikinci bir kopya basmak nadiren fayda verir. Unique kısıt da kendi indeksini getirir. “Bu kolon önemli” diye tekrar indeks eklemek, çoğu zaman yalnızca yazma yolunu uzatır.
İndeks iki işi hızlandırır: koşula uyan satırları bulmak ve sıralı okumak. Filtre, birleşim ve liste ekranındaki ORDER BY bu gruba girer. İndeks üç işi hızlandırmaz: filtresiz özet rapor, baştan jokerli metin araması ve tek başına çok az ayıran bayrak kolonları.
Kapsayan indeks, sorgunun ihtiyaç duyduğu kolonların tamamını indekste tutar; motor tabloya geri dönmez. Bu güçlü bir adımdır ama indeksi şişirir. Önce yavaş sorguyu görün, sonra her kolonu indekse yığmayın. SELECT * da kapsama şansını düşürür; liste ekranı gerçekten gereken alanları seçsin.
İndeks, kolonun itibarına göre değil sorgunun şekline göre seçilir.
Her kolona indeks basmak neden zarar verir
Her kolona indeks, ileride lazım olur gerekçesiyle basılır. Maliyet sessiz birikir. Her INSERT, UPDATE ve DELETE, tablonun yanı sıra o satırı ilgilendiren indeksleri de günceller. Yazma yolu uzar. Yedek, geri yükleme ve indeks bakımı büyür.
Kullanılmayan indeks yalnızca yer kaplamaz. Planlayıcıya fazladan seçenek sunar; bazen yanlış plan seçilir. Daha kritik olanı şudur: indeks yanlış kolondaysa yavaş liste yine yavaş kalır. “İndeks var” sanırsınız; plan hâlâ tam tarama gösterir. Sorun eksik indeks değil, sorgunun şekliyle indeksin şeklinin uyuşmamasıdır.
Şema çizilirken bütün WHERE adaylarına indeks koymak bir tasarım kararı değil, ertelenmiş bir ölçüm kaçışıdır. Özellikle stok, sayaç, son görülme gibi sık değişen kolonlar hem yazmayı hem indeksi yorar. Listeyi hızlandırmayan bir yapı için sürekli bakım ödemiş olursunuz.
Yavaş liste ve filtre sorgusunu nasıl ölçersiniz
Tahminle indeks basmayın. Önce yavaşlayan işi adlandırın: ürün listesi, sipariş arama, müşteriye göre fatura, tarih aralıklı hareket. Bir e-ticaret sitesinde bu iş çoğu zaman kategori filtresi, stok durumu ve fiyata göre sıralanan ürün listesidir; admin panelde ise sipariş no, müşteri ve tarih aralığıdır.
Sonra o işin SQL’ini yakalayın. Uygulama günlüğü, yavaş sorgu kaydı veya geliştirme ortamındaki aynı ekran yeter. Parametreleri gerçekçi tutun. Tek satır dönen test, üretimdeki binlerce satırlık filtreyi temsil etmez. “status = 1” ile “magaza_id = 17 AND status = 1 AND tarih arasında” aynı sorgu değildir.
Planı okuyun. EXPLAIN ve motorda varsa ANALYZE şunları gösterir:
- İndeks kullanılıyor mu, hangisi?
- Tahmini ve mümkünse gerçek satır sayısı ne?
- Sıralama için ekstra bir adım var mı?
- İndeksten tabloya geri dönüş var mı?
Ölçüm rutini sade tutulabilir:
- Ekranı veya API’yi tekrarlayan sorguyu kaydedin.
- Planı ve süreyi not edin; “yavaş”ı hissederek değil, aynı parametreyle karşılaştırın.
- Aday indeksi kopya veride ekleyin. Üretimde denemeyin.
- Aynı sorguyu tekrar çalıştırın. Yalnızca süreye bakmayın; plan gerçekten indekse döndü mü kontrol edin.
- Yazma yolunu da yoklayın. Kayıt ekleme ve güncelleme belirgin ağırlaştı mı?
KepezWeb tarafında özel PHP/MySQL yazılım işlerinde bu döngü, “kolon önemli görünüyor” tartışmasının yerini alır. İndeks, kanıtlanan sorguya bağlanır. Küçük ekipte bunu resmi bir kapasite projesine çevirmeniz gerekmez; yavaş ekranı listelemek ve planı kaydetmek yeter.
Hangi kolona indeks basılır: pratik çerçeve
Karar üç soruya iner. Bu kolon yavaş sorgunun WHERE veya JOIN koşulunda eşitlik ya da aralık olarak geçiyor mu? Bu sorgu sık çalışıyor mu, yoksa ayda bir rapor mu? Koşul sonucu tabloyu belirgin biçimde daraltıyor mu?
Geçmiyorsa indeks adayı değildir. Nadir çalışıyorsa yazma maliyeti ödemeyin. Daraltmıyorsa tek başına zayıf kalır. “durum = aktif” tablonun büyük kısmını bırakıyorsa motor indeksi kullanıp kullanmamakta haklı olarak tereddüt eder. “siparis_no = ?” gibi neredeyse tek satıra inen kolonlar güçlü adaydır.
Yabancı anahtar her motorda otomatik indeks değildir. JOIN’in sık kullanıldığı tarafta eşleşen kolon ölçülerek indekslenir. “FK var, öyleyse indeks vardır” varsayımı, liste ekranında sessiz taramaya yol açar.
Liste ekranlarında üç parça bir arada durur: filtre kolonları, sıralama kolonu ve sayfalama. Bunları ayrı ayrı tek kolon indeksleri olarak basmak yerine sorgunun gerçek WHERE ve ORDER BY kombinasyonuna bakın. OFFSET ile derin sayfalama, indeks olsa bile atlanan satırları işletebilir; anahtar ile devam etmek (son görülen tarih ve id) aynı bileşik indeksten daha temiz yararlanır.
Basılmayacak yerler nettir:
- Nadiren filtrelenen geniş metin ve açıklama alanları
- Sık güncellenen sayaç, anlık stok, son görülme
- Tek başına duran düşük seçicilikli bayraklar
- Zaten birincil anahtar veya unique ile kaplı kolonlar
- Uygulamanın hiç kullanmadığı, “raporda belki” kolonları
Küçük ekiplerde yazılım geliştirme işine bu soruları eklemek, şemayı şişirmeden liste ekranını ayakta tutmanın sade yoludur. KepezWeb de indeksi “kolon kataloğu” gibi değil, yavaş işin kanıtı gibi ele alır.
| Soru şekli | İndeks yaklaşımı | Dikkat |
|---|---|---|
| Eşitlik, yüksek seçicilik (sipariş no, e-posta) | Tek kolon veya unique | Unique varsa ikinci kopya gerekmez |
| Liste: eşitlik + tarih sıralama | Bileşik; eşitlik solda | Sıra, sorgudaki kullanıma uymalı |
| Düşük seçicilikli durum / bayrak | Tek başına zayıf | Başka kolonla bileşik düşünün |
| Sık JOIN edilen yabancı anahtar | Ölçerek indeks | Her FK otomatik çözüm değildir |
| Nadir rapor, geniş tarama | İndeksi erteleyin | Yazma ve bakım maliyeti ödersiniz |
Bileşik indeks: kolon sırası neden işi değiştirir
Bileşik indeks, birden fazla kolonu tek yapıda tutar. Sıra, telefon rehberindeki soyad–ad sırası gibidir: soyada bakmadan ada göre arayamazsınız. Soldan önek kuralı bundan ibarettir.
Pratik kural: eşitlik kolonları solda, aralık ve sıralama sağa doğru. Örnek: WHERE magaza_id = ? AND durum = ? ORDER BY olusturma_tarihi DESC. Aday sıra çoğu zaman (magaza_id, durum, olusturma_tarihi) olur. magaza_id olmadan yalnız olusturma_tarihi, bu sorguya tam fayda vermez. Tersine (olusturma_tarihi, magaza_id) soldan tutmaz.
Aynı kolon setini farklı sırada iki indeks olarak çoğaltmayın. Önce en sık sorguyu seçin. İkinci bir sıra ancak ayrı bir yavaş ekran ölçülürse konuşulur. (a, b) varken ayrıca yalnız (a) çoğu zaman gereksizdir; soldan önek zaten (a) aramasını karşılar. (b) tek başına aranıyorsa o ayrı bir sorudur ve ayrı ölçülür.
LIKE 'abc%' soldan tutabilir; LIKE '%abc' tutmaz. Klasik indeks, site içi serbest metin aramanın yerine geçmez. Metin araması ayrı bir problemdir; liste filtresindeki kategori ve durum ile karıştırmayın.
İndeksi izlemek, değiştirmek ve kaldırmak
İndeks bir kez basılıp unutulmaz. Sorgu değişir, ekran kalkar, rapor taşınır; indeks kalır. Periyodik bakın: hiç kullanılmayan indeksler, birbirini kapsayan tekrarlar, yazma yoğun tablodaki şişkin ikincil indeksler.
Kaldırmadan önce kopyada silip yavaş ekranları tekrar koşturun. Kullanım istatistiği “sıfır” görünse bile nadir ama kritik bir rapor o indekse bağlı olabilir. Canlıda ekleme ve silme, motor, sürüm ve tablo boyutuna göre kilit veya gecikme doğurabilir. Süre vaadi vermeden kopyada deneyin, bakım penceresini planlayın, geri alma adımını yazın.
Dağıtımdan sonra indeksleri bir gece tarayıp kapatmayın. Yavaş sorgu kaydını izlemeye devam edin. Yeni bir filtre eklendiğinde aynı çerçeveyi tekrar işletin: işi adlandırın, SQL’i yakalayın, planı okuyun, kopyada deneyin.
Sıkça Sorulan Sorular
Birincil anahtar varken başka indekse gerek var mı?
Birincil anahtar, id ile tek satır çekmeyi çözer. Liste ve filtre ise başka kolonlardan arar. Yavaşlayan WHERE, JOIN ve ORDER BY birincil anahtara sığmıyorsa ayrı indeks konuşulur; her kolona değil, ölçülen sorguya.
LIKE ile arama indeksten yararlanır mı?
Soldan sabit başlayan kalıp bazen yararlanır. Baştan jokerli arama klasik ağaç indeksini kullanamaz. Ürün adı veya açıklamada serbest arama istiyorsanız liste filtresi indeksinden ayrı bir çözüm düşünün.
İndeks ekledim, sorgu hâlâ yavaş. Neden?
Sıra uymuyor olabilir, seçicilik düşük olabilir, plan başka bir indeksi seçmiş olabilir, SELECT listesi tabloya geri dönüşü zorluyor olabilir. Önce EXPLAIN’e bakın. “İndeks var” ile “bu sorgu o indeksi kullanıyor” aynı şey değildir.
Düşük seçicilikli durum kolonuna indeks basılır mı?
Tek başına genelde zayıf kalır. Magaza, müşteri veya tarih gibi daraltan bir kolonla bileşik düşünün. Yalnızca evet/hayır tutan bir yapı, tablonun büyük kısmını bırakıyorsa tarama ile benzer iş çıkarır.
Canlıda indeks eklemek tabloyu kilitler mi?
Kilitleyebilir. Davranış motora, sürüme, tablo boyutuna ve o anki yazma yüküne göre değişir. Önce kopyada deneyin; canlıyı varsayılan laboratuvar gibi kullanmayın.
Liste ve filtre sorgularınızda tarama ile indeksi ayırmak, hangi kolona basılacağını da netleştirir. KepezWeb ile şema tahmini yerine ölçülen sorgu üzerinden ilerleyebilirsiniz. Kısa özeti ve yavaş ekranı paylaşmak için teklif formunu kullanabilirsiniz.
