SQL Hızlandırma İpuçları

 

SQL Hızlandırma İpuçları

Bu konuda birçok şey yazılabilir ve hala eksik kalabilir öncelikle onu belirtmek isterim.Ve DB’den DB’ye farkedebilir bazı şeyler ama biz genel olarak karşılaştığımız sorunları ve çözümleri üzerinden ilerleyelim umarım faydalı olur.

Bazı yöntemlerde sorgunuzu değiştirmeniz yeterli olabiliecekken bazılarında sizin veya DBA’nizin tablolara müdahele etmesi gerekebilir bunu unutmayın.

İpuçları yazmadan önce bahsetmek istediğim başka şeyler var.Bir SQL sorgusu nasıl çalışır bunu anlatmak istiyorum.

Bir sorguyu çalıştırdığınızda önce hata var mı diye kontrol edilir bu adımlar geçtikten sonra bu sorguyu çalıştıracak “motora” gönderilir.Fakat burada şöyle bir sıkıntı var sizin gönderdiğiniz sorgu mantıksal bir işlemdir bunun fiziksel olarak nasıl olacağına hangi yollar izlenerek bu sorgunun çalıştırıacağını “motor” birçok olası plan içinden seçer.Demekki biz bir sorguyu çalıştırdığımız anda bir çok plan oluşuyor en uygun ise en az maliyetli olan oluyor.Bu maliyet verdiğiniz hintlere,istatistiklere,indexlere bağlı olabiliyor.O yüzden her seferinde aynı sorguyu aynı plan ile çalıştırmayabilir bunu unutmayın.Biz hızlandırma derken aslında bu maliyeti düşürmeye çalışıyoruz 😊

 

 

·       Mümkün olduğunda ufak data setleri ile çalışın.

o   Bunu hemen biraz açmak istiyorum örneğin 50 sütunlu 100 milyon satırlı bir tablo ile 20 sütunlu 20 milyonluk iki tabloyu joinleyeceksiniz ama ilk tablodan sadece 1m diğerinden sadece 500k’lık bir kitleyi joinleyeceksek önce filtreleyip sonra joinlemek daha mantıklı olacaktır.

o   Bir diğer örnek ise örneğin bu iki tabloyu joinlediniz bir subqueryde üstte başka bir tablo ile joinleyeceksiniz sadece gerekli sütunları çağırın subquery’nin selectinde.Her sütun ek maliyet demektir.

·       Bir data setini bir kere kullanmaya dikkat edin.

o   Buna da hemen bir örnek verelim.Örneğin son 30 gün son 15 gün ve son 7 günün satış rakamlarına ihtiyacınız var.Bu durumda bu sorguyu 2 şekilde yazabilirsiniz.

Select

son30gun_satis,

son15gun_satis,

son7gun_satis

From

(

select count(*) son30gun_satis from satis_tablosu where satis_tarihi>=current_date-30

)   son30gun

Left join

(

select count(*) son15gun_satis from satis_tablosu where satis_tarihi>=current_date-15

)   son15gun on 1=1

Left join

(

select count(*) son7gun_satis from satis_tablosu where satis_tarihi>=current_date-15

)   son7gun on 1=1

Dikkat ederseniz satis_tablosunu 3 kere okudum bu x3 maliyet demektir.Peki ideal yöntem nedir?

select

count(*) son30gun_satis ,

count(case when satis_tarihi>=current_date-15 then id else null end ) son15gun_satis ,

count(case when satis_tarihi>=current_date-7 then id else null end ) son7gun_satis

from satis_tablosu

where satis_tarihi>=current_date-30

Gördüğünüz üzere tabloyu sadece 1 kere okudum.Unutmayın en çok maliyetlerden biri okuma sırasında meydana gelir.

 

o   Bir diğer önemli tek seferde okuma ise with’dir.Bir diğer ismi CTE(Common Table Expression).Eğer aynı subquery birden çok yerde kullanılacaksa bu durumda WITH ile hafızaya alıp tek bir kere okumak yine aynı okuma,join ve dönüşüm işlemlerini tekrar yapmakdan daha kısa sürecektir.Hemen bir örnek kod verelim.

Select

*

From table as aa

Left join (bir çok join ve dönüşüm içeren aynı subquery) as bb on aa.id=bb.id

Left join (bir çok join ve dönüşüm içeren aynı  subquery) as cc on aa.id=cc.id

Bunun yerine kod şöyle yazılmalıdır.Böylelikle tek bir kez hesaplama yapılır.

With subquery_hafizada as (bir çok join ve dönüşüm içeren aynı subquery)

Select

*

From table as aa

Left join subquery_hafizada as bb on aa.id=bb.id

Left join subquery_hafizada as cc on aa.id=cc.id

 

 

 

 

 

 

·       Where veya Joinde kullandığınız sütunları dönüşüm işlemlerine sokmayın.

Hemen bir örnek verelim.Aşağıdaki örnekte sütun1 indexli dahi olsa indexi kullanmayacaktır.Buda sorgunuzun performansını ciddi olarak azaltacaktır.Çünkü full scan yapacaktır.

Select

*

From table

Where CAST(sütun1 as DATE)=’2024-07-01’

Veya diğer bir örnek

Select

*

From table1

Left join table2 on table1.Ad=table2.Ad+table2.Soyad

·       ORDER BY kullanmayın!

o   İnanılmaz performans öldürücü methodtur zorunlu haller dışında kesinlikle kullanmayın yada çok ufak data setlerinde.

·       DISTINCT kullanmayın!

o   Çok ciddi performans düşürüdür kesinlikle kullanmayın dupliceliği çözebiliyorsanız çözün.

·       UNION kullanmayın

o   DISTINCT yaptığından yine performansı çok ciddi etkiler.

·       Indexli sütunlar kullanın.

o   Hem join hem wherede mümkün olduğunca sadece bu sütunları kullanmaya çalışın.Eğer yoksa yaratın çekinmeyin.

o   Fakat şunu unutmayın çok fazla index ciddi yer kaplar diskinizi doldurur herşeye index atılmamalıdır.

o   Eğer cadinatlity %30 üzerinde ise index mantıklı olabilir.Yani sadece 1 ve 0 olan bir sütuna index atmayın en az %30’u farklı değerlere sahip sütunlara index atın.

·       Partitionlı sütunlar kullanın.

o   Özellikle DWH yapılaırnda sıklıkla tercih ettiğimiz partitionlı tablolar partition sütunu kullanılmazsa yanıt bile vermeyecektir çoğu zaman muhakkak where ve joinlerinize ekleyin.

·       İstatistikleri güncellemeyi unutmayın.

o   İstatistikler en uygun execution planı seçmek için istatistiklere başvurur ne kadar güncel olursa o kadar uygun planı seçer.

·       IN yerine EXISTS kullanın.

o   IN yaptığınızda bir değeri bulduğunda dahi diğer satırları aramaya devam ederken EXISTS’de direk budum diyip sonraki değeri aramaya başlar o yüzden EXISTS her zaman daha hızlıdır.Hemen örnek bir kod yazalım.

Select

*

From table1

Where sutun1 IN (select sutun2 from table2)

Bunun yerine şöyle yazmak daha iyi olacaktır.

Select

*

From table1

Where exists (select 1 from table2 where table2.sutun2=table1.sutun1)

·       * kullanmayın.

o   Mümkünse hiç bir zaman selectlerinizde * kullanmayın bunun yerine sadece istediğiniz belirli sütunları isteyin.

·       Temp Tablolar kullanın

o   Temp tablolar veya geçici süreyle yarattığınız klasik tablolar kullanmaktan çekinmeyin.Özellikle ETL süreçlerinde sıklıkla kullandığımız bir methodtur inanılmaz performans arttırır işiniz bitince silersiniz.

o   Temp tablo olarak yarattığınızda session düştüğünde otomatik silinecektir ama uzun süren temp tablo yaratmalarında tavsiye etmem klasik olarak yaratın olurda session düşerse bir daha hesaplamak için dakikalar harcamazsınız kendiniz sonrasında silersiniz zaten.

·       DBLink Kullanmayın

o   Bazen ihtiyaçdan yapılabiliyor ama performans anlamında inanılmaz kötü mümkünse tabloyuda aynı veritabanınına alın network kaynaklı çok sorun yaşabilirsiniz.

·       View Kullanmayın

o   Viewler select veya joinlerde kullandığınızda her çağrılmada tekrar tekrar hesaplanıp geldiğinden önce view hesaplanıp sonrasında sizin query’iniz çalışır.Mümkünse tabloya basın viewlerinizi sonrasında tablodan çağırın bunun için elbette ETL süreci gerekir bunu yapamıyorsanız viewler üzerinde de index oluşturulabiliyor bu incelenebilir veya view’in performansı arttırılabilir.

·       Hintleri dikkatli olmak kaydı ile kullanın

o   Hintler hızlandıracağı kadar yavaşlatabilirde o yüzden çok dikkatli olun.Özellikle Oracleda PARALLEL,APPEND veya sql serverda NOLOCK,TABLOCKX gibi hintler çok yardımcı olurlar ama yerine göre tehlikelidir.

·       Table Scan yapıp yapmadığınıza dikkat edin

o   Eğer sorgunuz index veya partition kullanmıyorsa execution plana baktığınızda table scan görebilirsiniz bu ciddi bir sorundur.Eğer indexli bir tabloda indexli sütun üzerinden where yapmanıza rağmen table scan yapıyorsa bu durumda index rebuild edilebilir veya indexli sütunda dönüşüm yapılıp yapılmadığına bakılabilir.

·       Nested Loop Join kullanılıyor ise düzenleyin.

o   Çoğu DB’de 3 tip fiziksel join vardır.Bunlar İnner veya Left’den çok farklıdır.Inner veya Left mantıksaldır nasıl ilişkiye gireceklerini söylerken fiziksel join bunların nasıl okunup nasıl eşleştirileceğini gösterir.Nested loop iç içe iki for döngüsü gibi düşünebilir.bir tablodaki her bir kaydı diğer tabloda aratır.Hak vereceğiniz üzere bu 1 büyük 1 çok küçük tablo için mantıklıdır eğer sizin 2 büyük tablonuz nested loop yapıyorsa ya hintlerle bunu değiştirmesini zorlayabilirsiniz ya da index ve istatistisklerle başarabilirsiniz.Genelde DB’ler kolay kolay 2 büyük tablo için bu seçmez.

·       DML(DELETE,INSERT,UPDATE) log seviyesini en aza indirin.

o   Özellikle DWH’da log çok az önemlidir veri kaybı bizde kolay kolay söz  konusu değildir zaten kaynada vardır log minimum tutulaiblir bunun içinde Oracle’da APPEND,SQL Serverda TABLOCKX hintleri kullanılabilir tabi DB seviyesinde de minimum seçeneği seçilebilir.

·       DELETE yerine TRUNCATE edin.

o   Full tabloyu boşaltacaksanız TRUNCATE seçin log tutmaz.

·       Her zaman PL/SQL,T-SQL’lerinizde row by row değil bulk olarak işlemlerinizi yapın.

o   Örneğin bir tablonuz var 1m satır ve siz bir sütunu update edeceksiniz bu durumda 1m’lik bir loop’a sokup tek tek değil tek bir UPDATE sorgusunda bu işi yapın.

 

·       Like kullanmayın

o   Mümkünse like kullanmayın çünkü aranan string değerdeki tüm karakterileri incelediğinden çok yavaş olacaktır.Fakat içinde aratmayan sadece ‘XXX%’  bunun gibi yani XXX ile başlayanlar dediğimizde çok sorun yaşamayız çünkü tüm string aranmaz sadece ilk 3’e bakılır.

·       OR kullanmayın

o   Eğer OR ile yazmanız gereken bir ifade var ise bunu iki ayrı ifade ile yazıp UNION’lamak daha mantıklı olacaktır.Çünkü indexli olsalar dahi OR kullanımında indexler kullanılmayacaktır.Örnek verelim

Select

*

From table1 where sütun1=x or sütun2=y

Bunun yerine aşağıdaki daha mantıklı olacaktır.

Select

*

From table1 where sütun1=x 

Union

Select

*

From table1 where sütun2=y