Pip: Yavuz Filizlibay, bir yazıda dört farklı index dünyasını tek çatı altında toplamaya karar vermiş — B-tree, columnstore, JSON ve vector. Sıradan bir DBA için bu, tek bir menüde kebap, sushi, pizza ve moleküler gastronomi sunmak gibi.
Mara: Bu bölümde SQL Server 2025’in index stratejisini ele alıyoruz: hangi iş yükü için hangi index tipi, yeni gelen ordered nonclustered columnstore ve online build özellikleri, ve bunların hepsini bir arada nasıl kullanabileceğimiz. Hadi B-tree temellerinden başlayalım.
SQL Server 2025’te Index Ailesi: Dört Dünyayı Anlamak
Pip: Bu segmentin asıl sorusu şu: SQL Server 2025’te artık dört farklı index tipi var ve “index ekle” demek artık tek bir karar değil. Hangi tip, hangi kolonlar, hangi sıralama, hangi bakım stratejisi — bunların hepsi ayrı sorular.
Mara: Yazı bunu çok net koyuyor: “Artık index ekle demek dört ayrı kararı tetikliyor: hangi tip, hangi kolonlar, hangi sıralama, hangi maintenance stratejisi?”
Pip: Yani B-tree’nin tek kral olduğu dönem geride kaldı. OLTP için B-tree hâlâ vazgeçilmez, ama OLAP tarafında columnstore devreye giriyor.
Mara: B-tree tarafında temel mekanik şöyle: 100 milyon satırlık bir tabloda tipik derinlik dört seviye — root, iki intermediate katman ve leaf. Herhangi bir satıra dört sayfa erişimle ulaşılıyor. INCLUDE clause ile key olmayan kolonları leaf’e ekleyip Key Lookup’tan kurtulabiliyorsunuz.
Pip: Workshop 1 bunu sayılarla gösteriyor: sadece Country üzerine key-only index ile yaklaşık 2.300 logical read, INCLUDE ile Name ve Email eklendikten sonra yaklaşık 280 — sekiz kat düşüş.
Mara: Columnstore tarafında fark daha da dramatik. Workshop 2’de bir milyon satırlık fact tablo üzerinde aynı analitik sorgu: rowstore tarafta 1,4 saniye ve yaklaşık 25.000 logical read, columnstore tarafta 170 milisaniye ve yaklaşık 2.100 logical read.
Pip: Segment elimination’ın gücü tam burada görünüyor.
Mara: Evet. Columnstore’da her segment için min/max metadata tutuluyor; WHERE clause’a göre engine uyumsuz segmentleri hiç okumadan atlıyor. Test sonucunda 90 günlük filtreli sorguda yalnızca dört segment okunmuş, altısı metadata’dan elenmiş.
Pip: SQL Server 2025’in getirdiği en önemli yenilik ise ordered nonclustered columnstore. Eskiden bu yapı yalnızca clustered tarafta vardı.
Mara: Doğru. 2025 ile birlikte mevcut OLTP rowstore tablonuzun üzerine ordered nonclustered columnstore koyabiliyorsunuz — orijinal clustered organizasyonu bozmadan. Workshop 3 tam bunu gösteriyor: aynı Sales_RS tablosuna NCCSI eklenince reporting sorguları otomatik olarak columnstore’u kullanıyor, OLTP write’lar etkilenmiyor.
Pip: Bir trade-off var tabii: her INSERT, UPDATE ve DELETE NCCSI’yi de güncelliyor.
Mara: Yazı bunu açıkça belirtiyor: delta store ve tuple mover üzerinden ek I/O geliyor, yüksek-write tablolarda bu yük hissedilebilir. Disk alanı da artıyor, genellikle yüzde 20-40 ek alan.
Pip: Online build meselesi de önemli bir yenilik. Eskiden ordered columnstore için tabloyu offline almak gerekiyordu.
Mara: SQL Server 2025’te ORDER clause’lı CREATE INDEX artık ONLINE = ON ile çalışıyor. MAXDOP=1 ile inşa ederseniz engine tempdb bazlı sort kullanıyor ve segment overlap’ı sıfır olan fully ordered bir index üretiyor — build daha uzun sürer ama sonraki sorgu performansı maksimum.
Pip: JSON ve vector index ise karar matrisinin geri kalan iki köşesi.
Mara: JSON Index, JSON_VALUE, JSON_PATH_EXISTS ve JSON_CONTAINS predicate’lerini optimize ediyor; online build desteklemiyor, büyük tablolarda bakım penceresinde kurulması gerekiyor. Vector Index ise minimum 100 satır istiyor, şu an preview aşamasında ve PREVIEW_FEATURES açık olmalı. Karar matrisi net: OLTP için B-tree, OLAP için clustered columnstore, operational analytics için rowstore artı ordered nonclustered columnstore, JSON sorguları için JSON Index, AI/ML similarity search için vector index.
Pip: Index bakımı da var; fragmentation ve istatistik bayatlığı zamanla sessizce performansı eritiyor — bakım rutinlerini kurmadan ay sonu raporlama paniğine hazır olun.
Mara: Workshop 4 bunu somutlaştırıyor: sys.dm_db_index_physical_stats ile fragmentation ölçümü, yüzde 30 üstünde REBUILD, yüzde 10-30 arasında REORGANIZE. Columnstore tarafında ise sys.dm_db_column_store_row_group_physical_stats ile açık rowgroup’lar ve yüksek deleted_rows oranı izleniyor.
Pip: Dört index tipi, dört farklı karar — ama sonuçta hepsi aynı soruya dönüyor: bu iş yükü ne istiyor?
Mara: Ordered nonclustered columnstore ve online build, operational analytics senaryosunu gerçekten farklı bir yere taşıdı. Önümüzdeki bölümlerde bu konuların production’daki yansımalarını görmeye devam edeceğiz.