İlişkisel veritabanları özelinde yaşanan performans sorunlarına karşı almanız gereken önlemlerin neler olduğunu çoğumuz biliyoruz. INDEX’ler bu konuda en başı çeken yapılar. Bir index’in sağlayacağı faydayı başka bir yol ile elde etmemizin imkanı yok. Ama şu da unutulmamalıdır ki tablo üzerinde çok fazla index olması da başka performans sorunlarına neden olacaktır. Bu nedenle lütfen Veritabanı sunucunuzun önerdiği ya da eksik gördüğü indexleri gözü kapalı olarak yaratmayın.

Peki, index önerimiz yok ve hala sorgularımız yavaş çalışıyor ise neler değiştirebiliriz:

1-    Veri Tiplerinin Doğru Seçilmesi

VCHAR() veri tipi çoğu yazılımcının sevdiği bir veri tipi. Detayları bildiğinizi kabul ederek söyleyeyim, örneğin VARCHAR(20) olarak tanımlanan bir ISIM alanını okumak için SQL sunucu öncelikle Header kısmından içerideki verinin tam boyutunu öğrenmek zorunda. Zira buradaki veri 0’ da olabilir 20’ de. Ama aynı alanı CHAR(20) tanımlasa idik SQL sunucu kafadan 20bit’lik bir okuma yapacaktı.

Peki bu durumda ne öneririm? Birincisi telefon numarası, vergino gibi aşağı yukarı boyutu aynı olan alanların kesinlikle CHAR() olarak tanımlanması. İkinci olarak ta eğer alan(kolon) 5 karakterden küçük ise hiç VARCHAR olayına girmeyin.

2-    Veri CONVERT İşlemlerinden Uzak Durun

Bunu bilinçli olarak yapabilirsiniz. Bir sayısal değeri STRING’e ya da bir STRING alanını TARİH formatına çevirerek kullanmak okunan tüm veri için (mesela 1 Milyon Kayıt) bu işlemin yapılmasına neden olur. Bunu bilmeden de yapıyor olabilirsiniz. Karşılaştırdığınız iki alanın tanımı farklı ise SQL bunu arka planda uyguluyor olabilir. Tabii bir de bu CONVERT işlemi WHERE kısmında ise yolunuz FULL TABLE SCAN’e kadar gidebilir.

3-    Sorgunuzun “WHERE” kısmında FONKSİYON kullanmayın

Where DATE(birth_date)  ya da

Where CONCAT(firstname, ‘ ’, lastname) = ‘ömer zeybek’  gibi kullanımlar indexlerinizi de kullanım dışında bırakabilir. Tüm Index ya da daha kötüsü data page’lerinde okuma yapmak  ve fonksiyonu uygulamak zorunda kalabilirsiniz.

4-    “Select * from” kullanmamaya çalışın

Bu kullanım zaten yazılım standartları açısından da sorun yaratır. Tabloya eklenecek bir alan bir anda uygulamada umulmayan yerlerin hata almasına neden olur. Bizim açımızdan bakılır ise büyük ihtimal ile kullanılmayacak bazı alanların okunmasına delalettir.

5-    Bazı Ufak kısıtlamalar

• Group BY alanlarında DOUBLE ya da FLOAT veri tiplerinin kullanılması sorun yaratabilir.
• Distinct ile Group by gibi aslında aynı sonucu çıkaran komutların birlikte kullanılmasından kaçınılmalıdır.
• Çok fazla SUB_QUERY görünüş olarak güzel olsa da fazla TEMPDB ve RAM tüketeceği için kaçınılmalıdır. Tabii mümkün olduğu sürece.
• OR kullanarak JOIN yapılmasından da kaçınmak gerek

 6-    Text Search

Özellikle LIKE ile yapılan aramalar doğal olarak tüm tablonun okunması (index tanımlı ise tüm index page’lerinin okunması) ile gerçekleşir.

7-    Ufak bir Ek

Yukarıdaki anlatılanlara paralel olarak TARİH alanında bir sorgu çalıştırıyorsunuz diyelim. Eğer tablo çok büyük ise ya da çok hız isteniyor ise burada tarih alanını 3 ek kolon daha yaratabilirsiniz. Örneğin

YIL smallint, GUN smallint ve AY smallint şeklinde.

Bu 3 alan tarih alanında INSERT anında üretilir. 2022 yılı Ocak ayı raporu için sadece Yıl=2022 and ay=1 şeklînde çalışabiliriz.

8-    Kodlama

Buradaki kodlalama yazılım manasında değil. Diyelim ki firma ismi, belirli açıklamalar, departman isimleri gibi kendini tekrar eden alanlarınız mevcut.

yerine

Şeklinde olmadı gerekir. Firma isminin ya da departman isminin ne olduğunu ayrı bir tabloda tutabilirsiniz. Bu şekilde hem yerden(disk) büyük kazanç sağlayacaksınız hem de performansınız artacak.

Ömer ZEYBEK

Datarebus