Geçici (Temp) Tablolar Gerek Olmadığı Halde Kullanılıyor mu?
Geçici tablolar pratik bir kullanım sağlarken duruma göre fazla yük de getirebilirler. Yükten kurtarmak ve performansı iyileştirmek için geçici tablo kullanımını kaldıran farklı yöntemler kullanılabilir:
Stored Procedure Kullanılmış mı?
Stored procedure (SP)’ ler yazılımcılara ve sisteme birçok fayda sağlarlar. Network trafiğini ve bekleme süresini azaltıp uygulama performansını arttırırlar. Örneğin network üzerinde 500 satır TSQL göndermek yerine, daha hızlı çalışacak ve daha az kaynak kullanacak bir SP çalıştırma isteği göndermek yeterlidir. Ayrıca, SQL Server ara bellekte tutulan SP çalışma planları yeniden kullanılabilir.
İstemci uygulama taleplerinde SP kullanımı daha verimlidir. Örneğin, uygulamanın image tipinde veri kolonuna, SP kullanmadan büyük bir binary değer INSERT edilmesi gerekiyorsa, bu binary değeri karakter stringe dönüştürüp SQL Server’ a göndermesi gerekir. SQL Server bu değeri aldığında yeniden binary değere dönüştürerek sistem kaynaklarını verimsiz kullanmış olur. SP kullanımı bu sorunu elimine eder ve uygulamalardan parametre olarak binary değer göndermek mümkündür.SP’ ler T-SQL kodunun yeniden kullanımına yardımcı olurlar. Bu durum direk uygulama performansını arttırmaz, kod miktarını ve debug süresini azaltarak yazılımcıların verimliliğini arttırır.
T-SQL Dinamik Sorgu Çalıştırma Komutu Kullanılıyor mu?
Eğer dinamik bir T-SQL sorgu çalıştırılması gerekiyorsa, EXECUTE komutu yerine sp_executesql prosedürü kullanılmalıdır. Sp_executesql komutu iki temel avantaja sahiptir. Birincisi, kod yazarken daha fazla seçenek yaratan parametre kullanım desteği olmasıdır. İkincisi, SQL Server tarafından yeniden kullanılmak üzere çalışma planı (execution plan) yaratıyor olmasıdır. Bu da performans arttırmaya yardımcı olur.
Referential Integrity Kullanımları
Veritabanında gereksiz referential integrity olmamalıdır. Örneğin, referential integrity uygulamak için primary key ve foreign key kullanılıyorsa, aynı amacı gerçekleştirecek gereksiz trigger eklenmemelidir. Yine aynı işi yapacak constraints,/defaults veya constraints /rules kullanımları gereksiz yük getirecektir.
WHERE Deyimi Sargable mı veya İyileştirilebilir mi?
Sargable Deyimi, WHERE deyiminde sabit bir değerin bir kolonla karşılaştırılmasını işaret eden, "Search ARGument" kelimelerinden oluşan SARG kısaltmasından gelir. Eğer bir WHERE deyimi sargable ise sorgunun hızlı tamamlanmasını sağlayacak indeks avantajı var demektir [3]. Eğer WHERE (veya bir parçası) non-sargable bir deyim ise indeks avantajından yararlanılmaz ve table scan (tüm tabloyu tarama) işlemi gerçekleşir, bu da sorgu performansının düşmesine neden olur.
WHERE deyimlerindeki "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", ve "LIKE '%500'" gibi non-sargable arama argümanları genellikle (her zaman değil), arama gerçekleştirecek indeks kullanımına engel olurlar. Ek olarak, üzerinde bir fonksiyon bulunduran kolonların kullanıldığı deyimler, operatörün iki tarafında da aynı deyimi bulunduran deyimler, kolona dayalı karşılaştırmalar içeren deyimler non-sargable deyimlerdir.Non-sargable deyimler içeren WHERE cümleleri her zaman tablo tarama yapmayabilirler. Eğer WHERE cümlesi hem sargable hem non-sargable deyimler içeriyorsa, en azından sargable deyim için indeks kullanılır ve verinin hızlıca alınmasına yardımcı olur. Çoğu koşulda, tablo üzerinde sorgunun SELECT, JOIN, WHERE deyimlerindeki tüm kolonları içeren covering indeks varsa, WHERE deyimi non-sargable olsa bile tablo tarama yerine covering indeks taraması kullanabilir. Unutulmamalıdır ki covering indeksin de, okuma yaparken disk IO arttırma gibi indeks üretim tarafında dezavantajları vardır. Eğer WHERE deyiminin sargable olup olmadığı bilinmiyorsa, sorgu çalışma planı ile indeks kullanıp kullanmadığı kontrol edilebilir.
Sargable Operatörler:
Non-Sargable Operatörler:
Eğer NOT IN içeren bir sorgu varsa performans düşüşüne neden olur çünkü Query Optimizer bu aktiviteyi yerine getirmek için tüm tabloyu tarar. NOT IN yerine şu seçeneklerden biri kullanılabilir:
Eğer T-SQL deyiminde IN ve EXISTS arasında seçim yapma şansı varsa EXISTS kullanılmalıdır. Çünkü EXISTS daha randımanlı ve hızlı gerçekleşir.Eğer WHERE deyiminde IN veya OR kullandığımız zaman SQL Server indeks taraması yerine tablo tarama kullanıyorsa, indeks hint kullanarak Query Optimizer indeks kullanılacak duruma getirilebilir.
SELECT * FROM tblTaskProcesses WHERE nextprocess = 1 AND processid IN(8, 32, 45)
Yerine
SELECT * FROM tblTaskProcesses (INDEX =IX_ProcessID)WHERE nextprocess = 1 AND processid IN(8, 32, 45) gibi.
WHERE deyiminde IN veya BETWEEN kullanımı arasında seçme şansı varsa, BETWEEN kullanılması performans artışı sağlayacaktır.Mümkünse T-SQL kodunda string concat (birleştirme) işlemlerinden kaçınılmalıdır çünkü çok hızlı işlemler değillerdir ve uygulama performansının genelini düşürürler.Sorgunun WHERE deyimi OR operatörü içeriyorsa ve OR operatörünün referans aldığı kolonlardan biri indeksli değilse (veya kullanışlı bir indeksi yoksa) Query Optimizer bir tabloyu tamamen tarayabilir veya clustered indeks üzerinden tarama gerçekleştirebilir. Bu yüzden eğer birçok sorguda OR ifadesi kullanılıyorsa, referans gösterilen kolonların yararlı indeksleri olup olmadığından emin olunmalıdır.
Bir sorgu bir veya daha fazla OR deyimi içeriyorsa, performansı arttırmak için bazı koşullarda UNION ALL deyimleri birleşiminden oluşan seri ile yeniden yazılabilir.
Örneğin
SELECT employeeID, firstname, lastname FROM names WHERE dept = 'prod' OR city = 'Orlando' OR division = 'food'
Üç koşul ile ayrılan bu sorgunun indeks kullanabilmesi için OR yerine UNION ALL ile yeniden yazılması gereklidir:
SELECT employeeID, firstname, lastname FROM names WHERE dept = 'prod'
UNION ALL
SELECT employeeID, firstname, lastname FROM names WHERE city = 'Orlando'
UNION ALL
SELECT employeeID, firstname, lastname FROM names WHERE division = 'food'
Eğer uygulamada çok sayıda, CHAR ve VARCHAR kolon üzerinde genel arama karakterli (LIKE %) tekst arama yapılıyorsa, SQL Server Full Text Search seçeneğini kullanılması önerilir. Search Service, veritabanındaki aramayı önemli derecede hızlandırabilir.
Kaynaklar:
SQL Server: http://www.microsoft.com/ sqlserver/en/us/default.aspx
http://msdn.microsoft.com/en-us/library/ ms189826(v=sql.90).aspx
Geçici tablolar pratik bir kullanım sağlarken duruma göre fazla yük de getirebilirler. Yükten kurtarmak ve performansı iyileştirmek için geçici tablo kullanımını kaldıran farklı yöntemler kullanılabilir:
- İhtiyacı giderecek sorguyu standart sorgular veya stored procedure kullanarak yeniden yazmak
- Tablo veri tiplerini kullanmak
- İlişkili alt sorgular kullanmak
- Reel tablolar kullanmak.
- Geçici tabloya benzeyen UNION deyimleri kullanmak.
Stored Procedure Kullanılmış mı?
Stored procedure (SP)’ ler yazılımcılara ve sisteme birçok fayda sağlarlar. Network trafiğini ve bekleme süresini azaltıp uygulama performansını arttırırlar. Örneğin network üzerinde 500 satır TSQL göndermek yerine, daha hızlı çalışacak ve daha az kaynak kullanacak bir SP çalıştırma isteği göndermek yeterlidir. Ayrıca, SQL Server ara bellekte tutulan SP çalışma planları yeniden kullanılabilir.
İstemci uygulama taleplerinde SP kullanımı daha verimlidir. Örneğin, uygulamanın image tipinde veri kolonuna, SP kullanmadan büyük bir binary değer INSERT edilmesi gerekiyorsa, bu binary değeri karakter stringe dönüştürüp SQL Server’ a göndermesi gerekir. SQL Server bu değeri aldığında yeniden binary değere dönüştürerek sistem kaynaklarını verimsiz kullanmış olur. SP kullanımı bu sorunu elimine eder ve uygulamalardan parametre olarak binary değer göndermek mümkündür.SP’ ler T-SQL kodunun yeniden kullanımına yardımcı olurlar. Bu durum direk uygulama performansını arttırmaz, kod miktarını ve debug süresini azaltarak yazılımcıların verimliliğini arttırır.
T-SQL Dinamik Sorgu Çalıştırma Komutu Kullanılıyor mu?
Eğer dinamik bir T-SQL sorgu çalıştırılması gerekiyorsa, EXECUTE komutu yerine sp_executesql prosedürü kullanılmalıdır. Sp_executesql komutu iki temel avantaja sahiptir. Birincisi, kod yazarken daha fazla seçenek yaratan parametre kullanım desteği olmasıdır. İkincisi, SQL Server tarafından yeniden kullanılmak üzere çalışma planı (execution plan) yaratıyor olmasıdır. Bu da performans arttırmaya yardımcı olur.
Referential Integrity Kullanımları
Veritabanında gereksiz referential integrity olmamalıdır. Örneğin, referential integrity uygulamak için primary key ve foreign key kullanılıyorsa, aynı amacı gerçekleştirecek gereksiz trigger eklenmemelidir. Yine aynı işi yapacak constraints,/defaults veya constraints /rules kullanımları gereksiz yük getirecektir.
WHERE Deyimi Sargable mı veya İyileştirilebilir mi?
Sargable Deyimi, WHERE deyiminde sabit bir değerin bir kolonla karşılaştırılmasını işaret eden, "Search ARGument" kelimelerinden oluşan SARG kısaltmasından gelir. Eğer bir WHERE deyimi sargable ise sorgunun hızlı tamamlanmasını sağlayacak indeks avantajı var demektir [3]. Eğer WHERE (veya bir parçası) non-sargable bir deyim ise indeks avantajından yararlanılmaz ve table scan (tüm tabloyu tarama) işlemi gerçekleşir, bu da sorgu performansının düşmesine neden olur.
WHERE deyimlerindeki "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", ve "LIKE '%500'" gibi non-sargable arama argümanları genellikle (her zaman değil), arama gerçekleştirecek indeks kullanımına engel olurlar. Ek olarak, üzerinde bir fonksiyon bulunduran kolonların kullanıldığı deyimler, operatörün iki tarafında da aynı deyimi bulunduran deyimler, kolona dayalı karşılaştırmalar içeren deyimler non-sargable deyimlerdir.Non-sargable deyimler içeren WHERE cümleleri her zaman tablo tarama yapmayabilirler. Eğer WHERE cümlesi hem sargable hem non-sargable deyimler içeriyorsa, en azından sargable deyim için indeks kullanılır ve verinin hızlıca alınmasına yardımcı olur. Çoğu koşulda, tablo üzerinde sorgunun SELECT, JOIN, WHERE deyimlerindeki tüm kolonları içeren covering indeks varsa, WHERE deyimi non-sargable olsa bile tablo tarama yerine covering indeks taraması kullanabilir. Unutulmamalıdır ki covering indeksin de, okuma yaparken disk IO arttırma gibi indeks üretim tarafında dezavantajları vardır. Eğer WHERE deyiminin sargable olup olmadığı bilinmiyorsa, sorgu çalışma planı ile indeks kullanıp kullanmadığı kontrol edilebilir.
Sargable Operatörler:
- =
- <
- >
- <=
- >=
- EXISTS
- IS
- IN
- BETWEEN
- LIKE 'abc%'
Non-Sargable Operatörler:
- IS NULL
- <>
- !=
- !>
- !<
- NOT
- NOT EXISTS
- NOT LIKE
- LIKE '%abc'
- LIKE '%abc%'
- kolon1=kolon1
Eğer NOT IN içeren bir sorgu varsa performans düşüşüne neden olur çünkü Query Optimizer bu aktiviteyi yerine getirmek için tüm tabloyu tarar. NOT IN yerine şu seçeneklerden biri kullanılabilir:
- EXISTS veya NOT EXISTS kullanmak
- IN kullanmak
- LEFT OUTER JOIN gerçekleştirmek ve NULL durumunu kontrol etmek
Eğer T-SQL deyiminde IN ve EXISTS arasında seçim yapma şansı varsa EXISTS kullanılmalıdır. Çünkü EXISTS daha randımanlı ve hızlı gerçekleşir.Eğer WHERE deyiminde IN veya OR kullandığımız zaman SQL Server indeks taraması yerine tablo tarama kullanıyorsa, indeks hint kullanarak Query Optimizer indeks kullanılacak duruma getirilebilir.
SELECT * FROM tblTaskProcesses WHERE nextprocess = 1 AND processid IN(8, 32, 45)
Yerine
SELECT * FROM tblTaskProcesses (INDEX =IX_ProcessID)WHERE nextprocess = 1 AND processid IN(8, 32, 45) gibi.
WHERE deyiminde IN veya BETWEEN kullanımı arasında seçme şansı varsa, BETWEEN kullanılması performans artışı sağlayacaktır.Mümkünse T-SQL kodunda string concat (birleştirme) işlemlerinden kaçınılmalıdır çünkü çok hızlı işlemler değillerdir ve uygulama performansının genelini düşürürler.Sorgunun WHERE deyimi OR operatörü içeriyorsa ve OR operatörünün referans aldığı kolonlardan biri indeksli değilse (veya kullanışlı bir indeksi yoksa) Query Optimizer bir tabloyu tamamen tarayabilir veya clustered indeks üzerinden tarama gerçekleştirebilir. Bu yüzden eğer birçok sorguda OR ifadesi kullanılıyorsa, referans gösterilen kolonların yararlı indeksleri olup olmadığından emin olunmalıdır.
Bir sorgu bir veya daha fazla OR deyimi içeriyorsa, performansı arttırmak için bazı koşullarda UNION ALL deyimleri birleşiminden oluşan seri ile yeniden yazılabilir.
Örneğin
SELECT employeeID, firstname, lastname FROM names WHERE dept = 'prod' OR city = 'Orlando' OR division = 'food'
Üç koşul ile ayrılan bu sorgunun indeks kullanabilmesi için OR yerine UNION ALL ile yeniden yazılması gereklidir:
SELECT employeeID, firstname, lastname FROM names WHERE dept = 'prod'
UNION ALL
SELECT employeeID, firstname, lastname FROM names WHERE city = 'Orlando'
UNION ALL
SELECT employeeID, firstname, lastname FROM names WHERE division = 'food'
Eğer uygulamada çok sayıda, CHAR ve VARCHAR kolon üzerinde genel arama karakterli (LIKE %) tekst arama yapılıyorsa, SQL Server Full Text Search seçeneğini kullanılması önerilir. Search Service, veritabanındaki aramayı önemli derecede hızlandırabilir.
Kaynaklar:
SQL Server: http://www.microsoft.com/ sqlserver/en/us/default.aspx
http://msdn.microsoft.com/en-us/library/ ms189826(v=sql.90).aspx
Yorumlar
Yorum Gönder