Index her zaman hız katar mı?

Indexler, bazen sorguları yavaşlatabilir!

Index denince akla her zaman hızlı SQL'ler gelir değil mi? Evet, bir çok açıdan doğru bir algı. Fakat bazen indexlerin hızlandırmak yerine yavaşlattığını biliyor muydunuz? Bu yazımızda bu konuya biraz değineceğiz.

Index'lerin hızlandırmadığı noktalar...

Bir sorgunuzu hızlandırmak istiyorsunuz. İlk aklınıza gelen Index koymak ya da var olan indexleri kontrol etmek. Evet, bu doğru bir yöntem. Fakat indexler her zaman için sorgularınızı hızlandırmayacağı gibi tam aksine yavaşlatabilir.

Index oluşturma rehberi ile ilgili yazımız için lütfen tıklayınız...

Veri tabanları, yazılan sorgu sonucunda veriye ulaşmak için öncelikle execution plan ismi verilen bir plan oluştururlar. Bu planı okumayı iyi bilmenizi tavsiye ederim. Eğer where cümlesindeki sorguladığınız alanda index varsa, öncelikle bu index üzerinden gidilecek şekilde bir plan üretilebilir. Buraya kadar her şey normal. Fakat ulaşmak istediğiniz veri, tablonuzdaki toplam verinin büyük bir kısmını (>%20 yaklaşık) kapsıyorsa, bu durumda index üzerinden gitmek ekstra bir maliyet getirir. Bu maliyetin nasıl oluştuğunu aşağıdaki paragrafta açıklayalım:

Kısaca index üzerinden erişim: Veri tabanları index üzerinden veriye ulaşırken, önce indexe ulaşır, buradan ilgili verilerin fiziksel adresleri bazı algoritmalar ile bulunur. Sonra bu fiziksel adreslere gidilerek ilgili veri datafile üzerinden okunur ve ardından RAM'e taşınarak kullanıcıya ulaştırılır. Aslında çok daha karmaşık bir algoritması var ama bu yazımızda o kadar derine inmeyeceğiz.

Yukarıdaki işlemin her bir satır için yapıldığında ve getirilen verinin çok büyük olduğu durumda ne kadar çok maliyetli olacağını tahmin edebilirsiniz. İşte bu tip durumlarda imdadımıza Full Table Scan yöntemi yetişiyor.

Full Table Scan (FTS): Tablonun verilerini index üzerinden değil tüm satırların fiziksel adresleri üzerinden getirmeye yarayan bir veri getirme yöntemidir. Aşağıda basit bir SQL'in execution planını görüyoruz. FTS işlemleri görüldüğü üzere TOAD ara yüzünde kırmızı renkle gösterilmektedir. Bu ifadeyi gördüğünüzde, tablodaki ilgili verilere index üzerinden değil, full scan yaparak ulaşmakta olduğunu anlamalısınız. Bu durum çoğunlukla yavaşlığa neden olduğu için kırmızı ile dikkat çekilmiştir.

Peki, "bunu veri tabanı (Oracle, MySql, vs.) belirliyor, ben nasıl müdahale edebilirim ki" dediğinizi duyar gibiyim. Oracle'da SQL'ler içerisine hint'ler yazarak execution planı değiştirebilirsiniz. Yani ilgili veriye index üzerinden ya da FTS ile gitmesini bizzat siz söyleyebilirsiniz. Aşağıda, FTS ile gitmesini söylediğiniz örnek bir SQL yer almaktadır. Personel (ps) tablosuna giderken index kullanma diyoruz. Eğer başka tablolar için de benzer durum gerekiyorsa, her bir tablo için ayrı ayrı Full(tablo) ifadesini yazmalısınız.

select * /*+ full(ps) */ from personel ps
where sicil_no = 1342

Bazen veri tabanları, planı oluştururken FTS ile gitmeye karar verebilir. Bu karar mekanizmalarında birçok parametre rol oynar ama en önemlilerden bir tanesi tablo istatistikleridir. Bu verilerin güncel olması çok büyük öneme sahiptir. Bu karar doğru ya da yanlış da olabilir. Veri tabanlarının bu kararlarına tamamen güvenmenizi önermem. Eğer FTS yöntemi ile verilen plan kararının yanlış olduğunu düşünüyorsanız, ya da beklediğiniz performansı vermediyse bu durumda tam tersi, veri tabanını index kullanmaya yine hint vasıtasıyla zorlayabilirsiniz. Aşağıdaki örnekte personel tablosundaki personel_uix indexinin kullanması söyleniyor:

select * /*+ index(ps personel_uix) */ from personel ps
where sicil_no = 1342

Sonuç olarak: Tablonuzun, sorgunuzun, veri tabanınızın ve hatta sunucunuzun durumuna göre index ya da FTS ile verilerin getirilmesi kararı değişebilir. Hızlı olan yöntem de yine bu parametrelere göre değişir. SQL tuning eğitimlerinde bu konular derinlemesine anlatılmaktadır. Yeri geldikçe yazılarımızda bu konulara değiniyor olacağım.