Tüm Relational Database’lerde olduğu gibi SQL Server’da performans artışının en büyük destekçisi Index’lerdir. Index nedir? Ne işe yarar? Gibi sorulara burada cevap vermeyeceğiz. En azından bu bilgilere biraz aşina olanların okuması gereken bir yazı olacak. Ama giriş olması için her zaman verdiğimiz örneği burada da tekrarlamış olalım: “Nasıl bir kitapta bir konuyu ararken önce index sayfasına bakıp nerede olduğunu öğreniyoruz ve direkt olarak o sayfalara erişiyoruz, veritabanlarında da aynı mantık ile çalışan yapılardır. Kısaca hangi veri, nerede bilgisini verir bizlere. Aksi takdirde aynı kitaplarda olduğu gibi bütün tabloyu baştan sona gözden geçirmemiz gerekir.”
Yukarıdaki anlatılanlardan da anlaşılacağı üzere tablonuzda index var ise birkaç disk erişimi ile sorgunuzu tamamlarken, index olmayan durumlarda “full table scan” denilen tüm tablonun okunması kaçınılmazdır. Disk erişimlerinin veritabanlarında en yavaş kaynak olduğunu hatırlatalım.
Analizini yaptığımız pek çok SQL sunucuda index eksikliklerinden dolayı gereksiz performans kayıplarını görebiliyoruz. Ama bundan daha fazlası gereksiz ve yanlış kurgulanmış index yapılarının yarattığı sorunlar. “Index Tuning Wizard” gibi araçlar ile index gereksinimleri tespit edilip yaratılıyor. Bu işin kolay kısmı. Peki her ihtiyaç gerçekten de gerekli mi? bunu sormak ise bizim işimiz.
Index Yaratmadan Önce Düşünülecek 8 Şey:
1- Tabloya Göre Değil İş yüküne Göre İndex yaratılmalı
Diyelim ki yeni bir tablo yarattınız. Hemen index’ler ne olsun diye sormak yanlış. Zira bizim için mühim olan bu tabloda sorgulanacak olan alanların içerikleri ve sorgulama sayısı olacaktır.
2- Tablonun boyutları
Yukarıdaki maddeye ekleme olsun, özellikle parametre ya da tanım amaçlı kullanılan bazı ufak tablolara index yaratılması genelde gereksiz kaçabilir. Mesela bir disk okumasını 64K kabul eder isek, tablonun boyutuna göre yüzlerce kayıdı zaten tek seferde okuyacaktır. İndex yaratılması durumunda hem index hemtablo okunacağı için 1 okuma yerine 2 okuma yapılmış olacak.
3- Çok kullanılan sorgulara öncelik
Tabloda index sayısını arttırmamak adına mesela haftada 1 kere çalışıtırılan bir rapora ait sorgu yerine hergün çalışan bir sorguya index yaratılması daha uygun olacaktır. Tabii haftada bir çalışan sorguyu çalıştıran genel müdürünüz ise o ayrı.
4- “Cardinality” yani verideki çeşit sayısı
İndex yaratılırken o kolon kendi içerisinde ne derece farklı bilgiler taşıyor ise o kadar fazla performans artışına neden olur. Bu nedenle tarih kolonları güzel index örnekleri olabilir. 1 Milyon kayıt olan tabloda tarih üzerinden index yaratırsak yaklaşık 1Milyon index kayıdımız da olur. Ama mesela cinsiyet kolonunda yaratılacak bir index’ten aynı performansı göremeyiz zira yaklaşık 500Bin kayıt tek index kayıdı olarak karşımıza çıkacak.
Örneğin [cinsiyet + şehir] kolonlarında index yaratacak isek daha net bir erişim adına index’i [Şehir+ Cinsiyet] olarak yaratmak gerekir. Ne de olsa şehir sayısı cinsiyet sayısından daha fazla
5- Sadece “where” kısmına değil “Select” kısmına da bakmak gerekir
Select ad, soyad, sehir from table_name
Where ad = ‘omer’ and soyad = ‘Zeybek’
Sorgusunda eğer ad ve soyad kolonları üzerinde index var ise tablo direkt olarak kayıda erişir ama şehir bilgisi için tabloya da erişmek zorunda kalır. Eğer Şehir kolonunu da index’e ekler ise bu ikinci erişime gerek kalmayacaktır. Bunu gene 1 Milyon kayıtlı bir tablo için düşünürsek durum sadece 1 okuma fazla olmasının olmadığı net olarak anlaşılır. Tabii öncesinde tablodaki index sayısı ve bundan önceki tüm maddelere de bakmak gerekir. Yoksa her sorgu için bir index yaratmak gibi saçma bir süreç başlar.
6- Index içerisinde kolonların Update Edilme Sıklığı
Tüm update, Insert ve Delete işlemlerinden sonra index alanları da güncellenmek zorundadır. Bu özellikle clustered index yapılarında zorlayıcı bir durumdur aynı zamanda fragmantasyona da neden olur. Bu nedenle index kolonlarında mümkün olduğunca fazla güncelleme olmamasına dikkat etmeliyiz. En iyisi index’lerimiz ne kadar UPDATE almış diye kontrol etmek.
7- Sort ve Order By
Bu işlemler CPU üzerinde yoğunluk yaratacak işlemler olacaktır. Eğer index sayısı konusunda bir sıkıntımız yok ise ve CPU tek sorunumuz ise sırf bu işlemlerden kurtulmak için index yaratabiliriz.
8- Index’lerin ayrı bir disk üzerinde yaratılması
Çok performansa ihtiyacı olan sistemler için düşünülebilinir. Burada genelde bilinmeyeni söyliyelim Clustered index’leri ayrı bir diskte yaratmayın 😉
Kısacası internette rahatlıkla bulacağınız “hangi Index’leri Yaratmalıyım?” sorguları ile ya da zaten SQL SERVER ile beraber gelen “Index Tuning Wizard” yazılımları le hangi index’lere ihtiyaç olduğunuzu öğrenmek ve yaratmak çok kolay. Ama gerçekten size fayda sağlayacak Index’leri keşfetmek daha derin bir analize ihtiyaç duyuyor.
No responses yet