Sql'de Index Kavramlari...

Bu makalemde Sql'de kullanilan Index'ler hakkinda biraz bilgi verdikten sonra bir kac uygulama yaparak kullanimlari arasinda fark varmi yok mu bunlari gorecegiz. Oncelikle Index'in tanimini yapacak olursak; veritabanlarimizin barindirdigi tablolardan verileri sorgularken sureyi azaltmak istiyorsak bu yontemi kullaniyoruz. Ve esas amacimiz ise ; istenilen bilginin performans acisindan daha az veri okuyarak daha hizli bir sekilde kullanicilara getirilmesini saglamaktir. Peki bu Index'leme olayini neden kullanmaliyiz ; Eger ki cok satirlli tablolarimiz varsa, cok sik bir sekilde sorgulanan sutunlarimiz varsa, genellikle araliklar arasinda sorgulanarak taranan verilerimiz varsa, gruplanarak sorgulanan sutunlarimiz varsa veya sikca kullanilan join islemlerimiz varsa sorgularimizda bunlari surekli yazmamamiz icin olusturdugumuz index dosyalarimiz ile islerimizi daha kolaya indirgemis oluruz. Peki neleri Indexlememiz gerekiyor ; Cok az satirli olan tablolarimizi, az sorgulanan ve cok fazla degisiklige ugrayacak olan sorgularimizda, cok az bir sekilde kullandigimiz sutunlarda index kavramini kullanmamiz mantiksiz olacaktir. Bu index'leri MsSql kendi disk yonetiminde ozel bir yapi ile saklamaktadir... Tablo, sutun, view, index gibi yapilarin her biri aslinda Page (sayfa) denilen yapilar uzerinde saklamaktadir. Ve bir Page'in boyutu 8 KB'lik hafiza bloklarindan olusmaktadir. Buna bagli olarakta 8 Page bir Extend anlamina gelmektedir.

Sql Server bu page'ler de ki nesneleri saklarken gelisi guzel bir algoritma kullanmamaktadir, haliyle cok ozel bir yapiya sahip oldugu icin cok da ozel bir algoritmasi bulunmaktadir. Bu algoritmanin adi ; Balanced Tree' dir. Bu algoritmanin ozelligi index'ler de tablolar gibi Page'ler de barindirilmaktadir. Index'leri page'ler de ki hafizalarina yerlestirilirken bu algoritmanin kullanilmasinin tek amaci; HD'lerin verilere mumkun olduguinca daha az adimla is yaparak verinin bulundugu noktaya varmasidir. B-Tree kullanilarak aslinda Page'lerin birbirleriyle daha sik iletisimde bulunmasini da saglamaktadir. Ve her bir index icin atanmis page'ler kendisinden sonra gelecek olan page'in ilk kaydi ve page'in adresini tutacaktir. Index'lerimizi tanimlarken iki yontem kullanmaktayiz. Bunlardan birisi OLAP digeri ise OLTP yontemleridir. OLAP, genellikle okuma islemleri yaptigimiz zaman bu yontemi kullanmaktayiz. OLTP ise, bildigimiz uzere SQL' de ki CRUD islemlerde yogunlastigimiz zaman bu yontemi kullaniyoruz. Cok sik olmasada duydugumuz diger bir terim ise Heap'dir. Verilerimizin tablolara rastgele bir sekilde girilmesinden sonra yerlestirilmemesine yada siraya sokulmadan meydana gelen yapiya Heap diyoruz. Diyelim ki bu veriler siralanmis bir sekilde bulunuyorlarsa ve kullanici bunlari bu siraya gore verileri cekiyorsa bu yapiya Clustered Index diyoruz. Eger ki sorgulama yaparken birden fazla kritere gore verileri rastgele cekecek olursak da bu sefer yaptigimiz isleme Non - Clustered Index diyebiliriz. Kisacasi MsSql'imizde Indexes kullanirken ikiye ayrildigini hemen dile getirmis oldum ve simdi bunlari sirasiyla aciklayacagim.

Clustered Index ; Tablolarimizda bulunan kayitlarimizin fiziksel olarak Index'in tanimli oldugu sutuna gore siralanacaktir. Yandaki sekilde de gorulecegi gibi Leaf katmanlarinda gercek verilerimiz, kayitlarimiz bulunmaktadir.  Bir tarama islemi oldugunda son katmanda kaydimizin kendisine ulasmis oluyoruz. Bu index'leme yontemini kullandigimizda yaptigimiz taramalardan cok daha hizli sonuclar almaktayiz. Clustered Index Tanimlamamizda, sik sogrulanan islemlermizde, boyutu kucuk olan sutunlarimizda, ve genellikle degisimi sik olmayacak sutunlarimizin uzerinde islemler yaptigimiz zaman tercih etmekteyiz.

Non - Clustered Index ; Tablolarimizda ki kayitlarimiza dogrudan bir erisim saglamayacaktir, adim adim ilerleyecek ve ekstradan bir fazla katmanla yoluna devam edecektir. Heap yada clustered index uzerinden verilerimize erisebilecektir. Eger ki clustered index tanimlanmis bir tabloda bir de non-clustered index yapisi kullanildiysa islemlerini gerceklestirirken leaf seviyede bulunan clustered index'den yardim alacak ve yoluna devam edecektir. Yani bir nevi referans oluyorlar da diyebiliriz. Non - Clustered Index Tanimlamamizda, join ve where sorgulamalarimizda kriter alinan sutunlarimizi kullanabiliriz. Bununla birlikte, foreign key sutunlarimizi, primary key haricinde sik sik arama yaptigimiz sutunlarimizda bu indexleme yapisini kullanarak hiz kazandirabiliriz sorgulamalarimizda...

Yaptigimiz Index'leme islemlerinde Sql Server imizda; Execution Plan' i kullanarak yapilandirilmis katmanlari gorebiliyoruz. Bu yapilandirmalarin uzerine mouse'la geldiginizde kucuk kucuk raporlamalar karsiniza gelecektir. Index'leme icin kullandigimiz kod yapilari su sekildedir ;

Yeni bir Index olusturacaksak, Create - On cumlelerini kullaniyoruz. Create kelimesinden sonra yapacaginiz index'leme isleminin belirliyoruz; clustered index veya non-clustered index yapisini yaziyoruz. Sonrasinda olusturacagimiz index'in ismini belirledikten sonra on kelimesinden sonra hangi tabloda ve sutunda islem yapiyorsak onlari belirliyoruz.

Set Statistics komutlari ile birlikte yaptigimiz sorgulamalar hakkinda server'in kullandigi disk yapisinda yapilan islemler hakkinda bilgileri gorebiliyoruz liste halinde...

Yaptigimiz index'leri disable olarak ayarlayabiliyoruz.  

Bu komut ile bilikte tablomuzda ki index le ilgili bilgilere bagli olarak taranmis sayfalar hakkinda asagida ki gibi bilgiler verilmis olacaktir.