SQL Server İndeksleme: 10x Daha Hızlı Veritabanı Performansı Sırları

Yavaş çalışan sorguların ve performans sorunlarının veritabanınızı yavaşlatmasından sıkıldınız mı? SQL Server’da doğru indeksleme stratejileri, uygulamanızın performansını katlanarak artırabilir. Bu yazıda, veritabanınızı hızlandıracak indeksleme sırlarını, yaygın hataları ve uzmanların kullandığı optimizasyon tekniklerini paylaşacağım. İster deneyimli bir DBA, ister yeni başlayan bir geliştirici olun, bu pratik stratejiler sorgu yanıt sürelerinizi düşürmenize ve sistem kaynaklarınızı daha verimli kullanmanıza yardımcı olacak. Hazırsanız, SQL Server performansını on kat artırmanın yollarını keşfedelim!

İndeksleme Nedir ve Neden Önemlidir?

İndeksleme, veritabanı tablolarındaki veriye daha hızlı erişim sağlamak için kullanılan bir tekniktir. Tıpkı bir kitabın indeksinin belirli konuları hızlıca bulmanıza yardımcı olması gibi, veritabanı indeksleri de belirli veri satırlarını hızlı bir şekilde bulmaya yardımcı olur. İndeksleme, sorgu performansını önemli ölçüde artırabilir, özellikle büyük tablolarda. Ancak, yanlış indeksleme stratejileri performansı olumsuz etkileyebilir. İndeksler, veritabanı motorunun belirli sütunlardaki verilere hızlı bir şekilde ulaşmasını sağlayarak, tüm tabloyu tarama ihtiyacını ortadan kaldırır. Bu, özellikle sıkça kullanılan sorgularda büyük bir avantaj sağlar. İndekslemenin doğru yapılması, veritabanı sistemlerinin daha verimli ve hızlı çalışmasını sağlar.

İndekslemenin önemi, veritabanı performansını doğrudan etkilemesinden kaynaklanır. Doğru indeksler, sorgu sürelerini kısaltarak kullanıcı deneyimini iyileştirir, uygulama yanıt sürelerini hızlandırır ve genel sistem verimliliğini artırır. Ayrıca, indeksleme sunucu kaynaklarının daha verimli kullanılmasını sağlar, bu da maliyet tasarrufuna yol açabilir. Ancak, indekslemenin de bir maliyeti vardır. Her indeks, ek depolama alanı gerektirir ve veri ekleme, güncelleme ve silme işlemleri sırasında ek yük oluşturur. Bu nedenle, indeksleme stratejileri dikkatli bir şekilde planlanmalı ve uygulanmalıdır. Aşırı indeksleme, performansı olumsuz etkileyebilirken, yetersiz indeksleme de sorgu performansını düşürebilir.

Özetle, indeksleme veritabanı yönetiminde kritik bir rol oynar. Doğru indeksleme stratejileri, veritabanı performansını önemli ölçüde artırabilir, kullanıcı deneyimini iyileştirebilir ve kaynak kullanımını optimize edebilir. Ancak, indeksleme stratejilerinin dikkatli bir şekilde planlanması ve uygulanması, olumsuz etkileri en aza indirmek ve faydaları maksimize etmek için önemlidir. İndeksleme, veritabanı yöneticilerinin ve geliştiricilerinin sürekli olarak öğrenmesi ve geliştirmesi gereken bir alandır.

SQL Server’da İndeks Türleri

SQL Server, farklı ihtiyaçlara ve senaryolara uygun çeşitli indeks türleri sunar. Bu indeks türleri, veritabanı performansını optimize etmek için farklı avantajlar ve dezavantajlar sunar. En yaygın indeks türleri şunlardır:

• Kümelenmiş İndeksler (Clustered Indexes)
• Kümelenmemiş İndeksler (Non-Clustered Indexes)
• Bileşik İndeksler (Composite Indexes)
• Kapsayan İndeksler (Covering Indexes)
• Filtrelenmiş İndeksler (Filtered Indexes)
• Columnstore İndeksler

Her bir indeks türü, belirli sorgu türlerini hızlandırmak ve veritabanı performansını artırmak için tasarlanmıştır. Örneğin, kümelenmiş indeksler, verileri fiziksel olarak sıralayarak aralık sorgularını hızlandırırken, kümelenmemiş indeksler, belirli sütunlardaki verilere hızlı erişim sağlar. Bileşik indeksler, birden fazla sütunu içeren sorguları hızlandırırken, kapsayan indeksler, sorgunun ihtiyaç duyduğu tüm sütunları içerir. Filtrelenmiş indeksler, belirli bir koşulu karşılayan verilere hızlı erişim sağlarken, Columnstore indeksler, büyük veri ambarı sorgularını hızlandırır.

Bu indeks türlerinin her birinin nasıl çalıştığını ve ne zaman kullanılacağını anlamak, etkili bir indeksleme stratejisi oluşturmak için önemlidir. İlerleyen bölümlerde, her bir indeks türünü daha ayrıntılı olarak inceleyeceğiz ve en iyi kullanım senaryolarını tartışacağız. Ayrıca, her bir indeks türünün avantaj ve dezavantajlarını da değerlendireceğiz.

Kümelenmiş İndeksler (Clustered Indexes)

Kümelenmiş indeksler, SQL Server’da tabloların fiziksel depolama düzenini belirleyen temel indeks yapısıdır. Bu indeks türü, verileri indeks anahtarına göre mantıksal bir sırada depolar ve tablonun tüm verilerini yaprak düzeyde içerir.

Temel Özellikleri

• Bir tablo için yalnızca bir adet kümelenmiş indeks oluşturulabilir
• Tablodaki verilerin fiziksel depolama sırasını belirler
• B-Tree (dengeli ağaç) yapısında saklanır
• Ağacın yaprak düğümleri tablonun gerçek verilerini içerir
• Primary Key tanımlandığında, varsayılan olarak kümelenmiş indeks oluşturulur (aksi belirtilmedikçe)
• NULL değerler içeren sütunlar da kümelenmiş indeks olarak kullanılabilir

Avantajları

• Aralık sorgularında (BETWEEN, >, <, vb.) üstün performans sağlar
• ORDER BY ifadelerinde, indeks sırasıyla aynı olduğunda sıralama adımını ortadan kaldırır
• Kümelenmemiş indeksler için temel erişim yolu sağlar
• Tablodaki tüm veriler okunacaksa kümelenmiş indeks taraması, heap taramasından daha verimlidir
• İlişkisel veri erişiminde (JOIN işlemleri) yüksek performans sunar

Dezavantajları

• Veri manipülasyonu (INSERT, UPDATE, DELETE) işlemlerinde ek yük oluşturur
• Özellikle ortaya ekleme yapılan durumlarda sayfa bölünmelerine yol açabilir
• Geniş indeks anahtarları, tüm kümelenmemiş indeksleri de etkiler ve daha fazla depolama alanı gerektirir
• Sık güncellenen anahtar değerleri, sayfaların yeniden düzenlenmesine neden olabilir
• Yanlış anahtar seçimi, disk fragmentasyonuna yol açabilir

İdeal Kullanım Senaryoları

• Sık kullanılan aralık sorgularında (tarih aralıkları, sayısal değer aralıkları gibi)
• Sıralı erişim gerektiren sorgularda
• Benzersiz, artan değerlere sahip sütunlarda (örn. kimlik sütunları)
• Verinin doğal bir düzeni olduğunda (kronolojik veriler)
• Birleştirme (JOIN) işlemlerinde sık kullanılan anahtar sütunlarda

SQL Örneği ve En İyi Uygulamalar

-- Kümelenmiş indeks oluşturma
CREATE CLUSTERED INDEX CIX_Personel_SicilNo
ON Personel(SicilNo);

-- Primary Key üzerinde kümelenmiş indeks oluşturma
ALTER TABLE Satislar
ADD CONSTRAINT PK_Satislar PRIMARY KEY CLUSTERED (SatisID);

-- Kompozit kümelenmiş indeks
CREATE CLUSTERED INDEX CIX_Faturalar_MusteriID_Tarih
ON Faturalar(MusteriID, Tarih DESC);

En İyi Uygulamalar

• Küçük, sabit uzunluklu ve tekil sütunları tercih edin
• Artan değerlere sahip sütunları seçin (sayaçlar, tarihler)
• Sıkça güncellenen sütunlardan kaçının
• Veri erişim kalıplarınızı analiz ederek en uygun sütun(ları) seçin
• Kümelenmiş indekslerin FILLFACTOR parametresini veri değişim oranına göre ayarlayın
• İndeks fragmentasyonunu düzenli olarak kontrol edin ve yeniden düzenleyin

Kümelenmiş indeks seçimi, veritabanı performansını etkileyen en kritik kararlardan biridir. Tablonun kullanım deseni, veri karakteristiği ve sorgu ihtiyaçlarına göre doğru kümelenmiş indeks seçimi yapılmalıdır.

Kümelenmemiş İndeksler (Non-Clustered Indexes)

Kümelenmemiş indeksler, SQL Server’da veri erişimini hızlandıran ve tablonun fiziksel düzenini etkilemeden çalışan ayrı indeks yapılarıdır. Bu indeksler, veri satırlarını doğrudan içermek yerine, indeks anahtarlarını ve ilgili verilerin nerede bulunduğunu gösteren işaretçileri (pointer) içerir.

Kümelenmemiş İndekslerin Özellikleri

• Bir tabloda en fazla 999 adet kümelenmemiş indeks oluşturulabilir
• Tablodan bağımsız bir B-Tree yapısında saklanır
• İndeks yapısının yaprak düğümleri, gerçek verileri değil, veri satırlarına işaretçileri içerir
• Bu işaretçiler, tablo kümelenmiş indekse sahipse kümelenmiş indeks anahtarlarına, değilse satır kimliğine (RID) işaret eder
• Seçici WHERE koşullarında, özellikle eşitlik karşılaştırmalarında yüksek performans sağlar

Avantajları

• Belirli sütunlara göre filtreleme yapılan sorgularda erişim hızını artırır
• Tabloyu fiziksel olarak yeniden düzenlemeden birden fazla erişim yolu sağlar
• JOIN işlemlerinde ilişkisel sütunlar için ideal tercihdir
• INCLUDE ifadesi ile kapsayan indeks olarak kullanılabilir
• Unique kısıtlamaları kümelenmemiş indekslerle uygulanabilir

Dezavantajları

• Ek depolama alanı gerektirir
• Veri ekleme, güncelleme ve silme işlemlerinde ek yük oluşturur
• Çok fazla indeks olması bakım ve genel performansı olumsuz etkileyebilir
• Büyük veri kümeleri için tarama (scan) operasyonlarında kümelenmiş indeksler kadar etkili değildir

Örnek SQL Kodları

-- Temel kümelenmemiş indeks oluşturma
CREATE NONCLUSTERED INDEX IX_Musteriler_Email
ON Musteriler(Email);

-- Birden fazla sütun üzerinde kümelenmemiş indeks
CREATE NONCLUSTERED INDEX IX_Siparisler_MusteriID_SiparisTarihi
ON Siparisler(MusteriID, SiparisTarihi DESC);

-- Benzersiz kümelenmemiş indeks
CREATE UNIQUE NONCLUSTERED INDEX UIX_Kullanicilar_KullaniciAdi
ON Kullanicilar(KullaniciAdi);

-- INCLUDE ifadesi ile kapsayan indeks
CREATE NONCLUSTERED INDEX IX_Urunler_KategoriID
ON Urunler(KategoriID)
INCLUDE (UrunAdi, BirimFiyat, StokMiktari);

-- Filtrelenmiş kümelenmemiş indeks
CREATE NONCLUSTERED INDEX IX_Siparisler_AktifSiparisler
ON Siparisler(SiparisID, SiparisTarihi)
WHERE Durum = 'Aktif';

Kullanım Senaryoları

• Belirli bir değere göre (örneğin müşteri numarası, e-posta) arama yapılan sorgular
• Foreign key sütunları üzerinde (JOIN işlemlerini optimize etmek için)
• Sık kullanılan WHERE koşulları üzerinde
• ORDER BY veya GROUP BY ifadelerinde kullanılan sütunlar
• Kısıtlamaları uygulamak için (UNIQUE vb.)

En İyi Uygulamalar

• Sık sorgulanan, ancak nadir güncellenen tablolarda daha fazla indeks kullanılabilir
• Yüksek seçicilik (selectivity) oranına sahip sütunları indeksleyin
• İndeks boyutunu küçük tutun (mümkün olan en az sütunu kullanın)
• İndekslerin kullanımını düzenli olarak izleyin ve kullanılmayan indeksleri kaldırın
• Veri dağılımına dikkat edin – indeksler eşit olmayan veri dağılımlarında daha az etkili olabilir

Kümelenmemiş indeksler, doğru kullanıldığında sorgu performansını önemli ölçüde artırabilir, ancak her sorgu veya tablo için her zaman en iyi çözüm olmayabilir. Veritabanı şemanıza, veri karakteristiklerine ve sorgu desenlerinize bağlı olarak indeks stratejinizi optimize etmelisiniz.

Bileşik İndeksler (Composite Indexes)

Bileşik indeksler, SQL Server’da birden fazla sütunu tek bir indeks yapısında birleştiren güçlü performans araçlarıdır. Doğru tasarlandığında, sorgu yanıt sürelerini dramatik şekilde iyileştirebilir ve sistem kaynaklarının kullanımını optimize edebilirler.

Temel Özellikleri

• İki veya daha fazla sütundan oluşur
• Sütunların indeks içindeki sırası kritik önem taşır
• Hem kümelenmiş hem de kümelenmemiş indeksler bileşik olabilir
• Maksimum 16 sütun içerebilir (sınırlama toplam 900 byte’tır)
• Sorgu planı optimizasyonunda önemli rol oynar

Sütun Sırası ve Önemi

Bileşik indekslerde sütun sırası, indeksin etkinliğini belirleyen en önemli faktördür:

• Sol kenar prensibi: İndeks, yalnızca soldaki sütunlar sorgu koşullarında kullanıldığında verimli çalışır
• İlk sütun filtrelemede kullanılmıyorsa, indeks taraması yerine tablo taraması gerçekleşebilir
• Sıralama için kullanılan sütunlar, WHERE koşullarında kullanılan sütunlardan sonra gelmelidir
• En seçici (en fazla benzersiz değere sahip) sütunlar genellikle öne alınmalıdır

Kullanım Örnekleri

-- Temel bileşik indeks oluşturma
CREATE INDEX IX_Musteriler_Sehir_Yas 
ON Musteriler(Sehir, Yas);

-- Bileşik kümelenmiş indeks
CREATE CLUSTERED INDEX CIX_Siparisler_MusteriID_Tarih
ON Siparisler(MusteriID, SiparisTarih DESC);

-- INCLUDE ile kapsayan bileşik indeks
CREATE NONCLUSTERED INDEX IX_Urunler_KategoriID_TedarikciID
ON Urunler(KategoriID, TedarikciID)
INCLUDE (UrunAdi, Fiyat, StokMiktari);

Etkin Kullanım Senaryoları

• Birbiriyle ilişkili sütunlarda sık filtreleme yapılan sorgularda
• WHERE koşullarında AND operatörü ile birleştirilen sütunlarda
• JOIN ve GROUP BY işlemlerinde birlikte kullanılan sütunlarda
• Genel olarak birlikte sorgulanan sütun kombinasyonlarında
• Raporlama ve analiz amaçlı aralık sorgularında

Optimizasyon İpuçları

• Gerçek sorgu desenlerinizi analiz ederek en uygun sütun kombinasyonlarını ve sırasını belirleyin
• İndeksi tüm sorgu ihtiyaçlarını karşılayacak şekilde tasarlayın (INCLUDE kullanarak)
• İndeks boyutunu gereksiz yere artırmayın – her ek sütun bakım maliyeti ekler
• Tekrarlayan indekslerden kaçının (örn. IX_A_B ve IX_A indeksleri)
• DMA raporu veya sys.dm_db_index_usage_stats gibi araçlarla indeks kullanımını takip edin

Yaygın Hatalar

• Tüm sütun kombinasyonları için ayrı indeksler oluşturmak
• İndeksteki sütun sırasını sorgu desenlerine uygun tasarlamamak
• Veri değişim sıklığını göz ardı etmek
• İndeks kullanımını düzenli olarak izlememek
• Çok az veya çok fazla indeks oluşturmak

Bileşik indeksler, doğru tasarlandığında sorgu performansını önemli ölçüde artırabilir. Ancak, veritabanınızın iş yükünü, sorgu kalıplarını ve veri karakteristiklerini iyi anlamak, optimum indeks stratejisi geliştirmenin anahtarıdır. Düzenli izleme ve ince ayar yaparak, bileşik indekslerinizden maksimum fayda sağlayabilirsiniz.

Kapsayan İndeksler (Covering Indexes)

Kapsayan indeksler, SQL Server’da sorgu performansını dramatik şekilde artırabilen özel bir indeksleme tekniğidir. Bu indeksler, bir sorgunun ihtiyaç duyduğu tüm verileri indeks yapısı içinde barındırarak, veritabanı motorunun tabloya geri dönmesini (lookups) engeller. Bu optimizasyon, özellikle yoğun sorgu yükü olan sistemlerde önemli performans kazanımları sağlar.

Kapsayan İndekslerin Çalışma Prensibi

• İndeks, sorgunun ihtiyaç duyduğu tüm sütunları içerir
• Anahtar sütunlar (key columns) ve dahil edilen sütunlar (included columns) olmak üzere iki bölümden oluşur
• İndeks yapısı, tablo erişimi gerektirmeden sonuç kümesini oluşturabilir
• “İndeks ile kapsama” (Index Covering) olarak da bilinir
• Sorgu planlarında “Index Seek” veya “Index Scan” operasyonları ile kullanılır, “Key Lookup” operasyonu olmaz

SQL Server’da Kapsayan İndeks Oluşturma

-- INCLUDE anahtar kelimesi ile kapsayan indeks oluşturma
CREATE NONCLUSTERED INDEX IX_Satislar_TarihKapsayan
ON Satislar(SatisTarihi)
INCLUDE (MusteriID, UrunID, Miktar, BirimFiyat);

-- Bileşik indeksi kapsayan indeks olarak kullanma
CREATE NONCLUSTERED INDEX IX_Personel_DepartmanPerformans
ON Personel(DepartmanID, PerformansSkoru, IseBaslamaTarihi)
INCLUDE (Ad, Soyad, Maas, PozisyonID);

Avantajları

• Sorgu performansını önemli ölçüde artırır (2-10x hızlanma sağlayabilir)
• Table/Clustered Index erişimlerini ortadan kaldırır
• I/O operasyonlarını azaltır
• Kilit (locking) ve kaynak çekişmesini (contention) azaltır
• Özellikle sık çalıştırılan ve kritik sorgular için ideal çözümdür

Dikkat Edilmesi Gereken Noktalar

• Her sorgu için kapsayan indeks oluşturmak sürdürülebilir değildir
• INCLUDE bölümündeki sütunlar yalnızca yaprak düzeyde saklanır
• Çok geniş indeksler depolama alanı ve bakım maliyetlerini artırır
• DML operasyonları (INSERT, UPDATE, DELETE) sırasında tüm indekslerin güncellenmesi gerekir
• Kapsayan indeksler, veri değişikliği yoğun sistemlerde daha maliyetlidir

Optimum Kullanım İçin Öneriler

• Sorgu desenlerini analiz edin: Hangi sorguların kapsayan indekslerden en çok faydalanacağını belirleyin
• Sorgu düzeniyle ilgili istatistikleri izleyin: Query Store veya execution plan analizlerini kullanın
• Seçici olun: En önemli ve sık kullanılan sorgular için kapsayan indeksler tasarlayın
• Dikkatli planlayın:
  • Anahtar sütunlarını filtreleme ve sıralama için kullanılan sütunlardan seçin
  • INCLUDE bölümünde yalnızca gerekli sütunları ekleyin
  • İndeks boyutunu kontrol altında tutun
• Yeniden kullanımı maksimize edin: Birden fazla sorguyu destekleyebilecek kapsayan indeksler tasarlayın

Örnek Kullanım Senaryoları

• Raporlama ve analiz sorguları
• Dash panel, özet görünümleri ve toplu istatistikler
• Belirli özelliklerle filtrelenmiş veri listeleri
• Tablodaki toplam verinin küçük bir kısmını getiren sorgular

Gelişmiş Teknikler

• Filtrelenmiş İndeksler ile Kombinasyon: Veri alt kümeleri için daha küçük ve etkili kapsayan indeksler
• İndeks Birleştirme (Index Intersection): Sorgu optimizer’ın birden fazla indeksi birleştirerek kullanması
• İndeks Konsolidasyonu: Benzer indekslerin daha geniş bir kapsayan indekste birleştirilmesi

Kapsayan indeksler, doğru kullanıldıklarında sorgu performansını önemli ölçüde artırabilecek güçlü optimizasyon araçlarıdır. Ancak, veritabanı modeli, sorgu desenleri ve iş yükü karakteristiklerine göre dikkatle tasarlanmaları gerekir. Düzenli izleme ve ince ayar, kapsayan indekslerden maksimum fayda sağlamanın anahtarıdır.

Filtrelenmiş İndeksler (Filtered Indexes)

Filtrelenmiş indeksler, SQL Server’da 2008 sürümüyle birlikte sunulan ve veritabanı performansını önemli ölçüde iyileştirebilen güçlü bir optimizasyon aracıdır. Bu indeksler, tablodaki verilerin yalnızca belirli bir alt kümesi üzerinde oluşturularak, hem depolama alanından tasarruf sağlar hem de sorgu performansını artırır.

Temel Özellikleri

• Tablodaki verilerin belirli bir alt kümesi için indeks oluşturur
• WHERE koşulu kullanarak hangi satırların indeksleneceğini belirler
• Normal indekslere göre daha küçüktür ve daha az kaynak kullanır
• İstatistik bilgileri yalnızca filtrelenmiş veriler için tutulduğundan daha doğrudur
• Hem kümelenmemiş indekslerde hem de benzersiz indekslerde kullanılabilir

SQL Sözdizimi ve Örnekler

-- Temel filtrelenmiş indeks
CREATE NONCLUSTERED INDEX IX_Siparisler_TamamlanmislarTarih
ON Siparisler(SiparisTarihi)
WHERE Durum = 'Tamamlandı';

-- Birden fazla koşulla filtreleme
CREATE NONCLUSTERED INDEX IX_Urunler_AktifIndirimli
ON Urunler(UrunAdi, Fiyat)
WHERE AktifMi = 1 AND IndirimOrani > 0;

-- NULL değerler için filtrelenmiş indeks
CREATE NONCLUSTERED INDEX IX_Musteriler_EmailiOlanlar
ON Musteriler(Email, Ad, Soyad)
WHERE Email IS NOT NULL;

-- Filtrelenmiş benzersiz indeks
CREATE UNIQUE INDEX UX_Personel_AktifTcKimlik
ON Personel(TCKimlikNo)
WHERE Durum = 'Aktif';

-- Kapsayan filtrelenmiş indeks
CREATE NONCLUSTERED INDEX IX_Satislar_YuksekDegerli
ON Satislar(MusteriID, SatisTarihi)
INCLUDE (UrunID, Miktar, BirimFiyat, ToplamTutar)
WHERE ToplamTutar > 1000;

İdeal Kullanım Senaryoları

• Heterojen veri dağılımı: Bir sütunda az sayıda farklı değer olduğunda (örn. durum, kategori)
• NULL değer içeren sütunlar: NULL olmayan değerler üzerinde indeksleme yaparak
• Arşiv verileri: Aktif/pasif veya tarihsel/güncel veriler ayrımında
• Özel durum sorguları: Belirli kriterlere uyan kayıtlar için
• İş mantığına özel filtrelemeler: Stokta olan ürünler, aktif müşteriler, bekleyen siparişler gibi

Avantajları

• Daha küçük indeks boyutu, daha az disk alanı kullanımı
• Daha hızlı indeks bakımı ve daha az fragmentasyon
• Daha doğru istatistikler ve daha iyi sorgu planları
• Belirli veri alt kümeleri için benzersizlik zorlaması imkanı
• DML operasyonlarında (INSERT, UPDATE, DELETE) daha az genel yük

Dikkat Edilmesi Gereken Noktalar

• Parametre değişmezliği: Sorgu planı parametrelere göre optimize edilemeyebilir
• Karmaşık filtreler: Çok karmaşık filtreler bakım zorluğu yaratabilir
• Filtre uyumsuzluğu: Sorgu filtreleri ile indeks filtreleri arasındaki uyumsuzluk
• Örtük dönüşümler: WHERE koşullarında veri tipi uyumsuzlukları indeksi etkisiz hale getirebilir
• NULL değer davranışı: NULL değerlerle ilgili filtreleme davranışlarını iyi anlamak gerekir

En İyi Uygulama Önerileri

• İş ihtiyaçlarını ve sorgu desenlerini dikkatle analiz edin
• Sade ve basit filtreler kullanın, karmaşık ifadelerden kaçının
• Filtrelenmiş indeksi kullanacak sorguların WHERE koşullarıyla uyumlu filtreler tasarlayın
• Veri dağılımı istatistiklerini inceleyerek filtreleme etkisini ölçün
• Execution plan analizleriyle indeks kullanımını doğrulayın
• İndeks kullanım istatistiklerini düzenli olarak izleyin

Kısıtlamalar

• Filtre ifadesinde deterministik olmayan fonksiyonlar kullanılamaz
• OR operatörü yerine birden fazla filtrelenmiş indeks tercih edilmeli
• Karşılaştırma operatörleri (=, <, >, >=, <=, IS NULL vb.) kullanılabilir
• Computed column üzerinde filtrelenmiş indeks oluşturulabilir, ancak hesaplanmış sütun deterministik olmalıdır
• Filtrelenmiş indeksler, en iyi şekilde, sabit değerlerle doğrudan karşılaştırma yapan sorgularda çalışır

Filtrelenmiş indeksler, özellikle büyük tablolarda ve belirli veri alt kümeleri üzerinde sık sorgular yapılan sistemlerde önemli performans avantajları sağlar. Doğru tasarlandığında ve uygulandığında, hem depolama alanından tasarruf sağlar hem de sorgu yanıt sürelerini önemli ölçüde iyileştirir.

Columnstore İndeksler

Columnstore indeksler, SQL Server’ın 2012 sürümüyle tanıtılan ve özellikle veri ambarı (data warehouse) ve analitik işlem (OLAP) senaryolarında devrim yaratan özel bir indeks teknolojisidir. Geleneksel satır-odaklı depolama yerine, verileri sütun-odaklı olarak organize ederek, özellikle büyük veri kümelerinde çarpıcı performans iyileştirmeleri ve depolama verimliliği sağlar.

Çalışma Prensibi ve Temel Özellikleri

• Verileri satır yerine sütun bazında depolar
• Bir milyondan fazla satırı yaklaşık 1 milyon satırlık mantıksal gruplara (row groups) böler
• Her sütun ayrı ayrı sıkıştırılır ve depolanır
• Veri, segment adı verilen yapılar içinde düzenlenir
• İki temel tür: Kümelenmiş (Clustered) ve Kümelenmemiş (Nonclustered) Columnstore
• Batch Mode işleme sayesinde CPU verimli vektör işlemleri gerçekleştirir

Avantajları

• Üstün sıkıştırma oranları: Geleneksel B-Tree indekslere göre 10x’e kadar daha az depolama alanı
• Dramatik sorgu performansı: Analitik sorgularda 10-100x hızlanma
• Daha az I/O: Yalnızca sorgu için gerekli sütunlar okunur
• Gelişmiş bellek kullanımı: Daha az RAM gereksinimi ve daha verimli önbellek kullanımı
• Paralel işleme optimizasyonu: Daha iyi ölçeklenebilirlik
• Yüksek verimli veri sıkıştırma: Hem disk alanı tasarrufu hem de I/O azaltma
• Bellek içi (memory-optimized) tablo desteği: SQL Server 2016’dan itibaren

SQL Server’da Oluşturma ve Kullanım

-- Kümelenmiş Columnstore İndeks Oluşturma
CREATE CLUSTERED COLUMNSTORE INDEX CCI_SatisFakturalari
ON SatisFakturalari;

-- Kümelenmemiş Columnstore İndeks Oluşturma 
CREATE NONCLUSTERED COLUMNSTORE INDEX NCCI_SatisTarihi_UrunID
ON SatislarDetay(SatisTarihi, UrunID, Miktar, BirimFiyat);

-- Filtrelenmiş Columnstore İndeks (2016'dan itibaren)
CREATE NONCLUSTERED COLUMNSTORE INDEX NCCI_SatislarArsiv
ON Satislar(SatisTarihi, MusteriID, UrunID, Miktar, BirimFiyat, ToplamTutar)
WHERE SatisTarihi < '2023-01-01';

-- Columnstore ve B-tree kombinasyonu (2016'dan itibaren)
CREATE CLUSTERED COLUMNSTORE INDEX CCI_Urunler ON Urunler;
CREATE NONCLUSTERED INDEX IX_Urunler_UrunKodu ON Urunler(UrunKodu);

İdeal Kullanım Senaryoları

• Veri ambarı tabloları: Büyük olgu (fact) ve boyut (dimension) tabloları
• Analitik sorgular: SUM, COUNT, AVG, MIN, MAX gibi toplama işlemleri
• Rapor senaryoları: Çok sayıda satırı işleyen, geniş aralıklı sorgular
• Tarihsel veri analizleri: Nadiren güncellenen, çok sorgulanan veriler
• IoT ve telemetri verileri: Yüksek hacimli, append-only veri modelleri
• Hibrit işlem/analitik (HTAP) sistemleri: SQL Server 2016+ ile

Sürüm Bazında Gelişim

• SQL Server 2012: Salt okunur kümelenmemiş columnstore indeksler
• SQL Server 2014: Güncellenebilir kümelenmiş columnstore indeksler
• SQL Server 2016:
  • Güncellenebilir kümelenmemiş columnstore indeksler
  • OLTP tabloları için columnstore indeks kombinasyonları
  • Bellek içi tablolarda columnstore indeksler
• SQL Server 2017+:
  • Otomatik rowgroup sıkıştırması
  • Batch mode on rowstore
  • String fonksiyonlarında ve SORT operasyonlarında batch mode desteği

Dikkat Edilmesi Gereken Noktalar

• Delta Store Mekanizması: Veri değişiklikleri önce delta store’da tutulur, belirli bir eşik geçildiğinde compressed row group’a dönüştürülür
• Indeks Bakımı: Reorganize ve rebuild işlemleri columnstore indeksler için farklı davranır
• LOB Veriler: TEXT, NTEXT, IMAGE, VARCHAR(MAX) gibi LOB veri tipleri için bazı kısıtlamalar vardır
• Veri Yükleme Stratejileri: Bulk insert ve minimal logging önemlidir
• Segmentasyon Stratejisi: Doğru sütun seçimi ve sıralaması
• Kaynak Gereksinimleri: İndeks oluşturma ve bakım işlemleri için yeterli bellek gerekir

Optimizasyon İpuçları

• Minimal Logging: Bulk veri yüklemeleri için minimal logging kullanın
• Bellek Optimizasyonu: Columnstore operasyonları için yeterli bellek ayırın
• Segment Düzeni: Sık birlikte kullanılan sütunları gruplayın
• MAXDOP Ayarı: İndeks oluşturma ve sorgu çalıştırma için doğru MAXDOP değerlerini belirleyin
• Sıkıştırma Geciktirmesi: CREATE INDEX … WITH (DATA_COMPRESSION = COLUMNSTORE_ARCHIVE) kullanımı
• Rowgroup Kalitesi İzleme: sys.dm_db_column_store_row_group_physical_stats DMV’sini kullanarak rowgroup kalitesini izleyin
• Hibrit Yaklaşım: OLTP sistemlerde B-tree ve columnstore indeksleri bir arada kullanın

Sınırlamalar ve Dezavantajları

• OLTP İş Yükleri: Tekil kayıt ekleme/güncellemelerde daha düşük performans
• Yüksek DML Aktivitesi: Sık güncellenen tablolarda kaynakları daha fazla tüketir
• Sorgu Tipleri: Point lookup sorgularını (tekil kayıt erişimleri) optimize etmez
• Bakım Gereksinimleri: Fragmentasyon yönetimi için özel bakım rutinleri gerekebilir
• Bellek Gereksinimleri: Columnstore operasyonları daha fazla bellek gerektirebilir

Columnstore indeksleri, özellikle büyük veri kümelerinde analitik sorgular çalıştıran sistemlerde çarpıcı performans iyileştirmeleri sağlayan devrim niteliğinde bir teknolojidir. Doğru senaryoda kullanıldığında, geleneksel indeks yapılarına göre üstün performans ve depolama verimliliği sunar, ancak sistemin karakteristiklerine ve iş yükü profiline uygun şekilde planlanması ve yapılandırılması gerekir.

İndeks Tasarımı İlkeleri

İyi bir indeksleme stratejisi, veritabanı performansını önemli ölçüde artırabilir. Ancak, kötü tasarlanmış indeksler performansı olumsuz etkileyebilir. Bu nedenle, indeks tasarımı sırasında aşağıdaki ilkelere dikkat etmek önemlidir:

• Sorgu desenlerini analiz edin: Hangi sorguların en sık kullanıldığını ve hangi sütunların sorgularda kullanıldığını belirleyin.
• İndeks seçiciliğini göz önünde bulundurun: Daha seçici sütunlar, indeks anahtarının başına yerleştirilmelidir.
• Kapsayan indeksler oluşturun: Sorgunun ihtiyaç duyduğu tüm sütunları içeren indeksler oluşturun.
• Aşırı indekslemeden kaçının: Çok fazla indeks, performansı olumsuz etkileyebilir.
• İndeks boyutunu sınırlayın: Büyük indeksler, performansı olumsuz etkileyebilir.
• İndeks bakımını düzenli olarak yapın: İndekslerin düzenli olarak yeniden düzenlenmesi ve istatistiklerinin güncellenmesi önemlidir.

Bu ilkelere dikkat ederek, veritabanı performansını optimize eden etkili bir indeksleme stratejisi oluşturabilirsiniz.

İndeks Seçiciliği ve Önemi

İndeks seçiciliği, bir indeksteki benzersiz değerlerin oranını ifade eder. Yüksek seçiciliğe sahip bir indeks, her bir indeks değerinin az sayıda satırla ilişkili olduğu anlamına gelir. Düşük seçiciliğe sahip bir indeks ise, her bir indeks değerinin çok sayıda satırla ilişkili olduğu anlamına gelir.

İndeks seçiciliği, sorgu performansını önemli ölçüde etkiler. Yüksek seçiciliğe sahip indeksler, belirli satırları hızlı bir şekilde bulmaya yardımcı olurken, düşük seçiciliğe sahip indeksler, veritabanı motorunun daha fazla satırı taramasına neden olur. Bu nedenle, indeks tasarımı sırasında indeks seçiciliğini göz önünde bulundurmak önemlidir.

İndeks seçiciliğini artırmak için, daha seçici sütunlar indeks anahtarının başına yerleştirilmelidir. Ayrıca, filtrelenmiş indeksler kullanılarak, belirli bir koşulu karşılayan verilere hızlı erişim sağlanabilir.

İndeks Bakımı ve Yeniden Düzenleme

İndeksler, zamanla parçalanabilir ve performanslarını kaybedebilir. İndeks parçalanması, verilerin fiziksel olarak sıralanmamış olması ve indeks istatistiklerinin güncel olmaması durumunda ortaya çıkar. İndeks parçalanması, sorgu performansını düşürebilir ve kaynak kullanımını artırabilir.

İndekslerin düzenli olarak yeniden düzenlenmesi ve istatistiklerinin güncellenmesi, indeks performansını korumak için önemlidir. İndeks yeniden düzenleme, verilerin fiziksel olarak yeniden sıralanmasını ve indeks istatistiklerinin güncellenmesini içerir. İndeks yeniden düzenleme, sorgu performansını artırabilir ve kaynak kullanımını azaltabilir.

SQL Server, indeks yeniden düzenleme ve istatistik güncelleme işlemlerini otomatik olarak gerçekleştirmek için araçlar sunar. Ancak, bu işlemlerin manuel olarak da yapılması mümkündür. İndeks bakımının düzenli olarak yapılması, veritabanı performansını korumak için kritik öneme sahiptir.

İndeks Parçalanması ve Etkisi

İndeks parçalanması, veritabanı performansını olumsuz etkileyen bir durumdur. İndeks parçalanması, verilerin fiziksel olarak sıralanmamış olması ve indeks istatistiklerinin güncel olmaması durumunda ortaya çıkar. İndeks parçalanması, sorgu performansını düşürebilir ve kaynak kullanımını artırabilir.

İndeks parçalanmasının temel nedenleri, veri ekleme, güncelleme ve silme işlemleridir. Bu işlemler, indeks sayfalarının bölünmesine ve sıralamanın bozulmasına neden olabilir. İndeks parçalanması, özellikle sık sık veri ekleme, güncelleme ve silme işlemlerinin yapıldığı tablolarda daha sık görülür.

İndeks parçalanmasının etkilerini azaltmak için, indekslerin düzenli olarak yeniden düzenlenmesi ve istatistiklerinin güncellenmesi önemlidir. İndeks yeniden düzenleme, verilerin fiziksel olarak yeniden sıralanmasını ve indeks istatistiklerinin güncellenmesini içerir.

İndeks Kullanım İstatistiklerini Analiz Etme

İndeks kullanım istatistikleri, SQL Server veritabanınızın performansını iyileştirmek için kullanabileceğiniz en değerli araçlardan biridir. Bu istatistikler, veritabanı motoru tarafından tutulan ve hangi indekslerin ne şekilde kullanıldığını, hangilerinin atıl durumda olduğunu gösteren detaylı verilerdir. Doğru analiz edildiğinde, gereksiz indeksleri tespit edebilir, eksik indeksleri belirleyebilir ve genel veritabanı performansını önemli ölçüde artırabilirsiniz.

İndeks Kullanım İstatistiklerini Görüntüleme

SQL Server’da indeks kullanım verilerini görmek için çeşitli dinamik yönetim görünümleri (Dynamic Management Views – DMVs) bulunmaktadır:

-- En temel indeks kullanım istatistikleri sorgusu
SELECT 
    OBJECT_NAME(s.[object_id]) AS TableName,
    i.name AS IndexName,
    i.type_desc AS IndexType,
    s.user_seeks + s.user_scans + s.user_lookups AS TotalReads,
    s.user_seeks AS Seeks,
    s.user_scans AS Scans,
    s.user_lookups AS Lookups,
    s.user_updates AS Updates,
    s.last_user_seek AS LastSeek,
    s.last_user_scan AS LastScan,
    s.last_user_lookup AS LastLookup,
    s.last_user_update AS LastUpdate
FROM 
    sys.dm_db_index_usage_stats s
    INNER JOIN sys.indexes i ON s.[object_id] = i.[object_id] 
    AND s.index_id = i.index_id
WHERE 
    s.database_id = DB_ID()
ORDER BY 
    TotalReads DESC;

-- Kullanılmayan indeksleri tespit etme
SELECT 
    OBJECT_NAME(i.[object_id]) AS TableName,
    i.name AS IndexName,
    i.type_desc AS IndexType
FROM 
    sys.indexes i
    LEFT JOIN sys.dm_db_index_usage_stats s ON s.[object_id] = i.[object_id] 
    AND s.index_id = i.index_id AND s.database_id = DB_ID()
WHERE 
    i.is_primary_key = 0 -- PK indekslerini hariç tut
    AND i.[type] != 0 -- Heap'leri hariç tut
    AND (s.[object_id] IS NULL OR (s.user_seeks = 0 AND s.user_scans = 0 AND s.user_lookups = 0))
ORDER BY 
    TableName, IndexName;

Kritik Metrikler ve Anlamları

İndeks Kullanım Analizi Stratejileri

1. Kullanılmayan İndeksleri Tespit Etme

Hiç kullanılmayan veya nadiren kullanılan indeksler sistem kaynaklarını boşa harcar. Bu indeksleri tespit edip kaldırmak, DML performansını artırır ve depolama alanından tasarruf sağlar.

İpucu: İndeksi silmeden önce uzun süre (en az bir tam iş döngüsü) izleyin. Bazı indeksler yalnızca dönemsel işlemlerde kullanılabilir.

2. Yoğun Güncellemeli İndeksleri Değerlendirme

Çok fazla güncellenip az kullanılan indeksler, güncelleme maliyeti faydasından daha yüksek olabilir. Bu indekslerin:

• Filtrelenmiş indekslere dönüştürülmesi
• Daha az sütun içerecek şekilde yeniden tasarlanması
• Tamamen kaldırılması
• Güncellemelerin yoğun olmadığı zamanlarda yeniden oluşturulması

3. Verimsiz İndeks Desenlerini Tespit Etme

-- İndeks operasyon verimliliği analizi
SELECT 
    OBJECT_NAME(s.[object_id]) AS TableName,
    i.name AS IndexName,
    s.user_seeks AS Seeks,
    s.user_scans AS Scans,
    s.user_lookups AS Lookups,
    s.user_updates AS Updates,
    CASE WHEN s.user_updates > 0 
         THEN (s.user_seeks + s.user_scans + s.user_lookups) * 1.0 / s.user_updates 
         ELSE 0 
    END AS ReadWriteRatio
FROM 
    sys.dm_db_index_usage_stats s
    INNER JOIN sys.indexes i ON s.[object_id] = i.[object_id] AND s.index_id = i.index_id
WHERE 
    s.database_id = DB_ID()
ORDER BY 
    ReadWriteRatio ASC;

4. Eksik İndeksleri Belirleme

-- Eksik indeks önerileri
SELECT 
    DB_NAME(d.database_id) AS DatabaseName,
    OBJECT_NAME(d.[object_id]) AS TableName,
    d.equality_columns AS EqualityColumns,
    d.inequality_columns AS InequalityColumns,
    d.included_columns AS IncludedColumns,
    s.unique_compiles AS UniqueCompiles,
    s.user_seeks AS UserSeeks,
    s.user_scans AS UserScans,
    s.avg_total_user_cost AS AvgQueryCostReduction,
    s.avg_user_impact AS AvgUserImpact,
    (s.user_seeks + s.user_scans) * s.avg_total_user_cost * (s.avg_user_impact/100.0) AS PotentialImpact
FROM 
    sys.dm_db_missing_index_details d
    INNER JOIN sys.dm_db_missing_index_groups g ON d.index_handle = g.index_handle
    INNER JOIN sys.dm_db_missing_index_group_stats s ON g.index_group_handle = s.group_handle
ORDER BY 
    PotentialImpact DESC;

Düzenli İndeks Bakımı İçin En İyi Uygulamalar

1. İstatistik İzleme Rutini Oluşturun
   • Haftalık/aylık olarak indeks kullanım verilerini kaydedin
   • Trend analizleri yapın
   • Query Store ile birlikte kullanarak tam tablo taraması yapan kritik sorguları belirleyin
2. Otomatik İzleme Sistemi Kurun
   • Kullanılmayan indeksler için uyarı mekanizması oluşturun
   • Önceden tanımlanmış metriklerle indeks sağlığını ölçün
   • Düzenli raporlama mekanizması geliştirin
3. Stratejik İndeks Kararları Alın
   • Tamamen silmeden önce indeksi devre dışı bırakarak etkisini ölçün
   • İncelenen ve açık performans etkisi gösterilen indeksleri silin
   • Eksik indeks önerilerini inceleyerek uygun olanları ekleyin
   • İndekslerin sorgu planlarındaki etkisini gerçek sorgu örnekleriyle test edin
4. Belirli Sürelerde Kapsamlı İndeks Analizi Yapın
   • Her büyük versiyon yükseltmesinde
   • Uygulama veya veri modelindeki önemli değişikliklerden sonra
   • Performans sorunları yaşandığında
   • Yeni veya değiştirilmiş sorgu kalıplarının uygulanmasından sonra

İndeks kullanım istatistiklerinin düzenli analizi, SQL Server performans optimizasyonunun vazgeçilmez bir parçasıdır. Bu analiz, gereksiz indekslerin temizlenmesi, eksik indekslerin eklenmesi ve mevcut indekslerin iyileştirilmesi için somut veriler sağlar. Bu yaklaşım, hem disk alanı kullanımını azaltır hem de sorgu performansını artırır. Ayrıca, bakım pencerelerini kısaltır ve genel veritabanı sağlığını iyileştirir.

Sorgu Planlarını Okuma ve İndeks Önerilerini Değerlendirme

Sorgu planları, SQL Server’ın bir sorguyu nasıl yürüteceğini gösteren grafiksel veya metinsel gösterimlerdir. Sorgu planlarını okumak, sorgu performansını anlamak ve indeksleme önerilerini değerlendirmek için önemlidir. Sorgu planları, hangi indekslerin kullanıldığını, hangi işlemlerin yapıldığını ve hangi kaynakların kullanıldığını gösterir.

SQL Server Management Studio, sorgu planlarını görüntülemek için bir araç sunar. Bu araç, sorgu planlarını grafiksel olarak gösterir ve her bir işlemin maliyetini ve süresini gösterir. Sorgu planlarını analiz ederek, sorgu performansını etkileyen faktörleri belirleyebilir ve indeksleme önerilerini değerlendirebilirsiniz.

Sorgu planlarını analiz ederken, aşağıdaki noktalara dikkat etmek önemlidir:

• Hangi indeksler kullanılıyor?
• Hangi işlemler yapılıyor (örneğin, tablo taraması, indeks araması)?
• Her bir işlemin maliyeti ne kadar?
• Sorgu optimizasyonu için hangi öneriler sunuluyor?

Bu noktalara dikkat ederek, sorgu performansını iyileştirmek için gerekli adımları atabilirsiniz.

İndeksleme için En İyi Uygulamalar

İndeksleme, veritabanı performansını artırmak için güçlü bir araçtır. Ancak, indeksleme stratejisinin doğru bir şekilde planlanması ve uygulanması önemlidir. İndeksleme için en iyi uygulamalar şunlardır:

• Sorgu desenlerini analiz edin: Hangi sorguların en sık kullanıldığını ve hangi sütunların sorgularda kullanıldığını belirleyin.
• İndeks seçiciliğini göz önünde bulundurun: Daha seçici sütunlar, indeks anahtarının başına yerleştirilmelidir.
• Kapsayan indeksler oluşturun: Sorgunun ihtiyaç duyduğu tüm sütunları içeren indeksler oluşturun.
• Aşırı indekslemeden kaçının: Çok fazla indeks, performansı olumsuz etkileyebilir.
• İndeks boyutunu sınırlayın: Büyük indeksler, performansı olumsuz etkileyebilir.
• İndeks bakımını düzenli olarak yapın: İndekslerin düzenli olarak yeniden düzenlenmesi ve istatistiklerinin güncellenmesi önemlidir.
• İndeks kullanım istatistiklerini analiz edin: Hangi indekslerin kullanıldığını ve ne sıklıkla kullanıldığını belirleyin.
• Sorgu planlarını okuyun: Sorgu planlarını okuyarak, sorgu performansını etkileyen faktörleri belirleyin.
• İndeksleme stratejisini düzenli olarak gözden geçirin: Veritabanı yapısı ve sorgu desenleri değişebilir. Bu nedenle, indeksleme stratejisini düzenli olarak gözden geçirmek ve güncellemek önemlidir.

Bu en iyi uygulamalara dikkat ederek, veritabanı performansını optimize eden etkili bir indeksleme stratejisi oluşturabilirsiniz.

Aşırı İndekslemenin Zararları

İndeksleme, veritabanı performansını artırmak için kullanılan bir tekniktir. Ancak, aşırı indeksleme performansı olumsuz etkileyebilir. Aşırı indeksleme, çok fazla indeks oluşturmak veya gereksiz indeksler oluşturmak anlamına gelir.

Aşırı indekslemenin zararları şunlardır:

• Ek depolama alanı gereksinimi: Her indeks, ek depolama alanı gerektirir. Aşırı indeksleme, veritabanının boyutunu artırabilir.
• Veri ekleme, güncelleme ve silme işlemlerinde ek yük: Her indeks, veri ekleme, güncelleme ve silme işlemleri sırasında güncellenmelidir. Aşırı indeksleme, bu işlemlerin süresini uzatabilir.
• Sorgu optimizasyonunda karmaşıklık: Çok fazla indeks, sorgu optimizatörünün doğru indeksi seçmesini zorlaştırabilir.
• İndeks bakımında ek yük: Her indeksin düzenli olarak yeniden düzenlenmesi ve istatistiklerinin güncellenmesi gerekir. Aşırı indeksleme, indeks bakımının süresini uzatabilir.

Bu nedenle, indeksleme stratejisi dikkatli bir şekilde planlanmalı ve yalnızca gerekli indeksler oluşturulmalıdır.

İndeks Oluşturma ve Silme Stratejileri

İndeks oluşturma ve silme stratejileri, veritabanı performansını optimize etmek için önemlidir. İndeks oluşturma stratejisi, hangi indekslerin oluşturulacağını ve ne zaman oluşturulacağını belirler. İndeks silme stratejisi ise, hangi indekslerin silineceğini ve ne zaman silineceğini belirler.

İndeks oluşturma stratejisi, aşağıdaki faktörleri göz önünde bulundurmalıdır:

• Sorgu desenleri: Hangi sorguların en sık kullanıldığını ve hangi sütunların sorgularda kullanıldığını belirleyin.
• İndeks seçiciliği: Daha seçici sütunlar, indeks anahtarının başına yerleştirilmelidir.
• Kapsayan indeksler: Sorgunun ihtiyaç duyduğu tüm sütunları içeren indeksler oluşturun.
• Performans testleri: İndeks oluşturduktan sonra, sorgu performansını test edin.

İndeks silme stratejisi, aşağıdaki faktörleri göz önünde bulundurmalıdır:

• İndeks kullanım istatistikleri: Hangi indekslerin hiç kullanılmadığını veya çok az kullanıldığını belirleyin.
• Sorgu planları: Sorgu planlarını analiz ederek, hangi indekslerin gereksiz olduğunu belirleyin.
• Performans testleri: İndeks sildikten sonra, sorgu performansını test edin.

İndeks oluşturma ve silme stratejileri, veritabanı performansını optimize etmek için düzenli olarak gözden geçirilmelidir.

Tam Metin İndeksleme (Full-Text Indexing)

Tam metin indeksleme, metin verilerini içeren sütunlarda arama yapmak için kullanılan bir tekniktir. Tam metin indeksleme, LIKE operatörü veya diğer metin arama tekniklerine göre daha hızlı ve daha esnek bir arama sağlar. Tam metin indeksleme, özellikle büyük metin verilerini içeren tablolarda önemlidir.

SQL Server, tam metin indeksleme için bir özellik sunar. Bu özellik, metin verilerini analiz eder, kelimeleri ayırır ve bir indeks oluşturur. Bu indeks, metin verilerinde hızlı ve etkili bir şekilde arama yapmayı sağlar.

Tam metin indeksleme, aşağıdaki avantajları sunar:

• Hızlı ve esnek metin araması: Tam metin indeksleme, LIKE operatörü veya diğer metin arama tekniklerine göre daha hızlı ve daha esnek bir arama sağlar.
• Dil desteği: Tam metin indeksleme, birden fazla dili destekler.
• Özelleştirilebilir arama: Tam metin indeksleme, arama kriterlerini özelleştirmeyi sağlar (örneğin, eş anlamlı kelimeler, yakınlık araması).

Tam metin indeksleme, metin verilerini içeren uygulamalar için önemli bir özelliktir.

Geçici Tablolar için İndeksleme Stratejileri

Geçici tablolar, sorgular sırasında geçici olarak oluşturulan tablolardır. Geçici tablolar, genellikle karmaşık sorguları basitleştirmek veya ara sonuçları saklamak için kullanılır. Geçici tablolar için indeksleme stratejileri, normal tablolar için indeksleme stratejilerinden farklı olabilir.

Geçici tablolar için indeksleme stratejileri, aşağıdaki faktörleri göz önünde bulundurmalıdır:

• Geçici tablonun boyutu: Küçük geçici tablolar için indeks oluşturmak gerekmeyebilir.
• Geçici tablonun kullanım süresi: Kısa süreli geçici tablolar için indeks oluşturmak gerekmeyebilir.
• Geçici tabloyu kullanan sorgular: Geçici tabloyu kullanan sorguların desenlerini analiz edin.

Geçici tablolar için indeksleme stratejisi, geçici tablonun özelliklerine ve kullanım şekline göre belirlenmelidir. Genellikle, geçici tablolarda indeks oluşturmak, performansı artırabilir. Ancak, aşırı indeksleme performansı olumsuz etkileyebilir.

Büyük Tablolar için İndeksleme Yaklaşımları

Büyük tablolar için indeksleme, veritabanı performansını optimize etmek için kritik öneme sahiptir. Büyük tablolar için indeksleme yaklaşımları, normal tablolar için indeksleme yaklaşımlarından farklı olabilir.

Büyük tablolar için indeksleme yaklaşımları, aşağıdaki faktörleri göz önünde bulundurmalıdır:

• İndeks boyutu: Büyük indeksler, performansı olumsuz etkileyebilir. Bu nedenle, indeks boyutunu sınırlamak önemlidir.
• İndeks bakımı: Büyük indekslerin yeniden düzenlenmesi ve istatistiklerinin güncellenmesi, uzun sürebilir. Bu nedenle, indeks bakımını optimize etmek önemlidir.
• Bölümlenmiş indeksler: Bölümlenmiş indeksler, büyük tabloları daha küçük parçalara ayırarak, indeksleme ve bakım işlemlerini hızlandırabilir.
• Filtrelenmiş indeksler: Filtrelenmiş indeksler, belirli bir koşulu karşılayan verilere hızlı erişim sağlayarak, indeks boyutunu azaltabilir.

Büyük tablolar için indeksleme stratejisi, tablonun özelliklerine ve kullanım şekline göre belirlenmelidir. Genellikle, büyük tablolarda indeks oluşturmak, performansı artırabilir. Ancak, indeksleme stratejisinin dikkatli bir şekilde planlanması ve uygulanması önemlidir.

OLTP ve OLAP Sistemleri için İndeksleme Farklılıkları

OLTP (Online Transaction Processing) ve OLAP (Online Analytical Processing) sistemleri, farklı amaçlara hizmet eden veritabanı sistemleridir. OLTP sistemleri, gerçek zamanlı işlemleri desteklemek için tasarlanmıştır (örneğin, bankacılık işlemleri, e-ticaret siparişleri). OLAP sistemleri ise, veri analizi ve raporlama için tasarlanmıştır (örneğin, satış trendlerini analiz etmek, müşteri davranışlarını anlamak).

OLTP ve OLAP sistemleri için indeksleme stratejileri farklıdır. OLTP sistemlerinde, hızlı veri ekleme, güncelleme ve silme işlemleri önemlidir. Bu nedenle, indeksleme stratejisi, bu işlemleri optimize etmeye odaklanmalıdır. OLAP sistemlerinde ise, karmaşık sorguların hızlı bir şekilde yürütülmesi önemlidir. Bu nedenle, indeksleme stratejisi, bu sorguları optimize etmeye odaklanmalıdır.

OLTP sistemleri için indeksleme stratejileri, aşağıdaki özellikleri içermelidir:

• Az sayıda indeks: Aşırı indeksleme, veri ekleme, güncelleme ve silme işlemlerini yavaşlatabilir.
• Dar indeksler: Geniş indeksler, depolama alanı gereksinimini artırabilir ve performansı olumsuz etkileyebilir.
• Yüksek seçiciliğe sahip indeksler: Yüksek seçiciliğe sahip indeksler, belirli satırları hızlı bir şekilde bulmaya yardımcı olur.

OLAP sistemleri için indeksleme stratejileri, aşağıdaki özellikleri içermelidir:

• Çok sayıda indeks: Karmaşık sorguları hızlandırmak için çok sayıda indeks oluşturulabilir.
• Geniş indeksler: Sorgunun ihtiyaç duyduğu tüm sütunları içeren geniş indeksler oluşturulabilir.
• Columnstore indeksler: Büyük veri ambarı sorgularını hızlandırmak için Columnstore indeksler kullanılabilir.

OLTP ve OLAP sistemleri için indeksleme stratejileri, sistemin amacına ve kullanım şekline göre belirlenmelidir.

İndeksleme ve Veri Bütünlüğü

Veri bütünlüğü, verilerin doğru, tutarlı ve güvenilir olmasını ifade eder. İndeksleme, veritabanı performansını artırmak için kullanılan bir tekniktir. Ancak, indeksleme stratejisi, veri bütünlüğünü korumayı da göz önünde bulundurmalıdır.

İndeksleme, veri bütünlüğünü aşağıdaki şekillerde etkileyebilir:

• Veri tutarsızlığı: İndeksler, verilerin bir kopyasını içerir. Veriler güncellendiğinde, indekslerin de güncellenmesi gerekir. İndeksler güncellenmezse, veri tutarsızlığı oluşabilir.
• Performans sorunları: Yanlış indeksleme stratejileri, veri ekleme, güncelleme ve silme işlemlerini yavaşlatarak, veri bütünlüğünü etkileyebilir.

Veri bütünlüğünü korumak için, aşağıdaki önlemler alınmalıdır:

• İşlemler: Veri ekleme, güncelleme ve silme işlemleri, işlemler içinde gerçekleştirilmelidir. İşlemler, ya tüm değişikliklerin uygulanmasını ya da hiçbirinin uygulanmamasını sağlar.
• Kısıtlamalar: Kısıtlamalar, verilerin belirli kurallara uymasını sağlar. Örneğin, bir sütunun benzersiz olmasını veya belirli bir aralıkta olmasını sağlamak için kısıtlamalar kullanılabilir.
• Tetikleyiciler: Tetikleyiciler, belirli olaylar meydana geldiğinde otomatik olarak çalışan kodlardır. Örneğin, bir veri satırı güncellendiğinde, tetikleyici çalışarak, ilgili indeksleri güncelleyebilir.

İndeksleme stratejisi, veri bütünlüğünü korumayı göz önünde bulundurarak planlanmalıdır.

İndekslerin Yedekleme ve Geri Yükleme Üzerindeki Etkisi

Yedekleme ve geri yükleme, veritabanı yönetiminin önemli bir parçasıdır. Yedekleme, verilerin bir kopyasının oluşturulmasını sağlar. Geri yükleme ise, yedekten verilerin geri yüklenmesini sağlar. İndeksler, yedekleme ve geri yükleme süreçlerini etkileyebilir.

İndekslerin yedekleme ve geri yükleme üzerindeki etkileri şunlardır:

• Yedekleme süresi: İndeksler, yedekleme boyutunu artırabilir ve yedekleme süresini uzatabilir.
• Geri yükleme süresi: İndeksler, geri yükleme süresini uzatabilir. Geri yükleme sırasında, indekslerin yeniden oluşturulması gerekebilir.
• Yedekleme alanı gereksinimi: İndeksler, yedekleme alanı gereksinimini artırabilir.

Yedekleme ve geri yükleme süreçlerini optimize etmek için, aşağıdaki önlemler alınabilir:

• Sıkıştırılmış yedekleme: Sıkıştırılmış yedekleme, yedekleme boyutunu azaltır ve yedekleme süresini kısaltır.
• Bölümlenmiş yedekleme: Bölümlenmiş yedekleme, büyük veritabanlarını daha küçük parçalara ayırarak, yedekleme ve geri yükleme işlemlerini hızlandırır.
• İndeksleri devre dışı bırakma: Geri yükleme sırasında, indeksler devre dışı bırakılabilir ve geri yükleme tamamlandıktan sonra yeniden oluşturulabilir.

İndeksleme stratejisi, yedekleme ve geri yükleme süreçlerini göz önünde bulundurarak planlanmalıdır.

İndeksleme ve Sorgu Optimizasyonu İlişkisi

Sorgu optimizasyonu, bir sorgunun en verimli şekilde yürütülmesini sağlamak için yapılan işlemlerdir. İndeksleme, sorgu optimizasyonunun önemli bir parçasıdır. Doğru indeksler, sorgu optimizatörünün en iyi yürütme planını seçmesine yardımcı olur.

İndeksleme ve sorgu optimizasyonu arasındaki ilişki şöyledir:

• İndeksler, sorgu optimizatörüne veri erişim yolları sağlar: Sorgu optimizatörü, indeksleri kullanarak, tablolardaki verilere daha hızlı erişebilir.
• Sorgu optimizatörü, indeksleri kullanarak, en iyi yürütme planını seçer: Sorgu optimizatörü, farklı indeksleri ve veri erişim yollarını değerlendirerek, en iyi yürütme planını seçer.
• Yanlış indeksleme stratejileri, sorgu optimizatörünü yanıltabilir: Yanlış indeksleme stratejileri, sorgu optimizatörünün yanlış indeksi seçmesine ve kötü bir yürütme planı oluşturmasına neden olabilir.

Sorgu optimizasyonunu iyileştirmek için, aşağıdaki önlemler alınmalıdır:

• Doğru indeksler oluşturun: Sorgu desenlerini analiz ederek, doğru indeksler oluşturun.
• İndeks istatistiklerini güncel tutun: İndeks istatistikleri, sorgu optimizatörüne veri dağılımı hakkında bilgi sağlar. İndeks istatistiklerini düzenli olarak güncel tutmak, sorgu optimizatörünün daha iyi kararlar vermesine yardımcı olur.
• Sorgu ipuçlarını kullanın: Sorgu ipuçları, sorgu optimizatörüne belirli bir indeksi kullanmasını veya belirli bir yürütme planını seçmesini söyleyen direktiflerdir. Sorgu ipuçları, sorgu optimizatörünün varsayılan davranışını geçersiz kılmak için kullanılabilir.

İndeksleme ve sorgu optimizasyonu, veritabanı performansını artırmak için birlikte çalışır.

İndeksleme Performansını Ölçme ve İzleme

İndeksleme performansını ölçme ve izleme, indeksleme stratejisinin etkinliğini değerlendirmek için önemlidir. İndeksleme performansını ölçme ve izleme, hangi indekslerin iyi performans gösterdiğini ve hangi indekslerin iyileştirilmesi gerektiğini belirlemeye yardımcı olur.

İndeksleme performansını ölçmek ve izlemek için, aşağıdaki metrikler kullanılabilir:

• Sorgu süresi: Sorgu süresi, bir sorgunun yürütülmesi için geçen süreyi ifade eder. İndeksleme stratejisi, sorgu sürelerini azaltmalıdır.
• CPU kullanımı: CPU kullanımı, sorgu yürütülmesi sırasında kullanılan CPU kaynaklarını ifade eder. İndeksleme stratejisi, CPU kullanımını azaltmalıdır.
• Disk G/Ç: Disk G/Ç, sorgu yürütülmesi sırasında diske okuma ve yazma işlemlerini ifade eder. İndeksleme stratejisi, Disk G/Ç’nü azaltmalıdır.
• İndeks kullanım istatistikleri: İndeks kullanım istatistikleri, hangi indekslerin kullanıldığını ve ne sıklıkla kullanıldığını gösterir.

SQL Server, indeksleme performansını ölçmek ve izlemek için çeşitli araçlar sunar:

• SQL Server Profiler: SQL Server Profiler, SQL Server’da gerçekleşen olayları izleyen bir araçtır. SQL Server Profiler, sorgu sürelerini, CPU kullanımını ve Disk G/Ç’nü ölçmek için kullanılabilir.
• Performance Monitor: Performance Monitor, sistem performansını izleyen bir araçtır. Performance Monitor, CPU kullanımını, Disk G/Ç’nü ve diğer sistem kaynaklarını ölçmek için kullanılabilir.
• Dynamic Management Views (DMV’ler): DMV’ler, SQL Server hakkında bilgi sağlayan dinamik görünümlerdir. DMV’ler, indeks kullanım istatistiklerini ve diğer performans metriklerini görüntülemek için kullanılabilir.

İndeksleme performansını düzenli olarak ölçmek ve izlemek, indeksleme stratejisinin etkinliğini değerlendirmek için önemlidir.

Gelişmiş İndeksleme Teknikleri

Gelişmiş indeksleme teknikleri, veritabanı performansını daha da artırmak için kullanılabilir. Gelişmiş indeksleme teknikleri, genellikle daha karmaşık ve uzmanlık gerektiren tekniklerdir.

Gelişmiş indeksleme teknikleri şunlardır:

• Bölümlenmiş indeksler: Bölümlenmiş indeksler, büyük tabloları daha küçük parçalara ayırarak, indeksleme ve bakım işlemlerini hızlandırır.
• Filtrelenmiş indeksler: Filtrelenmiş indeksler, belirli bir koşulu karşılayan verilere hızlı erişim sağlayarak, indeks boyutunu azaltır.
• Columnstore indeksler: Columnstore indeksler, büyük veri ambarı sorgularını hızlandırır.
• Bellek içi OLTP: Bellek içi OLTP, verileri bellekte saklayarak, veri erişimini hızlandırır. Bellek içi OLTP, indeksleme performansını da artırabilir.
• Spatial indeksler: Spatial indeksler, coğrafi verileri indekslemek için kullanılır. Spatial indeksler, harita uygulamaları ve coğrafi analizler için önemlidir.

Gelişmiş indeksleme teknikleri, belirli senaryolarda veritabanı performansını önemli ölçüde artırabilir. Ancak, bu tekniklerin dikkatli bir şekilde planlanması ve uygulanması önemlidir.

İndeksleme Stratejilerini Test Etme ve Doğrulama

İndeksleme stratejilerini test etme ve doğrulama, indeksleme stratejisinin etkinliğini değerlendirmek için önemlidir. İndeksleme stratejilerini test etme ve doğrulama, indeksleme stratejisinin sorgu performansını artırıp artırmadığını ve veri bütünlüğünü koruyup korumadığını belirlemeye yardımcı olur.

İndeksleme stratejilerini test etmek ve doğrulamak için, aşağıdaki adımlar izlenebilir:

• Test ortamı oluşturun: Test ortamı, üretim ortamına benzer bir ortam olmalıdır.
• Test verileri yükleyin: Test verileri, üretim verilerine benzer olmalıdır.
• Test sorguları çalıştırın: Test sorguları, üretimde kullanılan sorguları temsil etmelidir.
• Performans metriklerini ölçün: Sorgu sürelerini, CPU kullanımını ve Disk G/Ç’nü ölçün.
• Veri bütünlüğünü doğrulayın: Veri bütünlüğünü koruduğundan emin olun.

İndeksleme stratejilerini test etmek ve doğrulamak, indeksleme stratejisinin etkinliğini değerlendirmek için kritik öneme sahiptir.

Sonuç ve En İyi Uygulamalar Özeti

Bu yazıda, SQL Server için veritabanı indeksleme stratejilerini ayrıntılı olarak inceledik. İndekslemenin temellerinden başlayarak, farklı indeks türlerini, tasarım ilkelerini, bakım gereksinimlerini ve gelişmiş teknikleri ele aldık. Amacımız, veritabanı yöneticilerine ve geliştiricilerine, sorgu performansını optimize etmek, kaynak kullanımını azaltmak ve genel sistem verimliliğini artırmak için gereken bilgi ve araçları sağlamaktı.

İndeksleme, veritabanı performansını artırmak için güçlü bir araçtır. Ancak, indeksleme stratejisinin doğru bir şekilde planlanması ve uygulanması önemlidir. İndeksleme stratejisi, sorgu desenlerini analiz etmeyi, indeks seçiciliğini göz önünde bulundurmayı, kapsayan indeksler oluşturmayı, aşırı indekslemeden kaçınmayı, indeks boyutunu sınırlamayı ve indeks bakımını düzenli olarak yapmayı içermelidir.

En iyi uygulamaların özeti şöyledir:

• Sorgu desenlerini analiz edin ve doğru indeksler oluşturun.
• İndeks seçiciliğini göz önünde bulundurun ve daha seçici sütunlar indeks anahtarının başına yerleştirin.
• Kapsayan indeksler oluşturun ve sorgunun ihtiyaç duyduğu tüm sütunları indeksleyin.
• Aşırı indekslemeden kaçının ve yalnızca gerekli indeksleri oluşturun.
• İndeks boyutunu sınırlayın ve büyük indekslerden kaçının.
• İndeks bakımını düzenli olarak yapın ve indeksleri yeniden düzenleyin ve istatistiklerini güncelleyin.
• İndeks kullanım istatistiklerini analiz edin ve gereksiz indeksleri silin.
• Sorgu planlarını okuyun ve sorgu performansını etkileyen faktörleri belirleyin.
• İndeksleme stratejilerini test edin ve doğrulayın ve performans metriklerini ölçün.
• İndeksleme stratejisini düzenli olarak gözden geçirin ve veritabanı yapısı ve sorgu desenleri değiştikçe güncelleyin.

Bu en iyi uygulamaları izleyerek, veritabanı performansını optimize eden etkili bir indeksleme stratejisi oluşturabilirsiniz.