Test sonrası, 4 milyondan fazla kayıt içeren bir tabloda koşullu bir sorgu yapıldı ve sorgu süresi 40 saniyeye kadar ulaştı. Bu nedenle, SQL ifade sorgusunun verimliliğini nasıl artırabileceği çok önemlidir. Aşağıda, internette yaygın olarak dolaşan birkaç sorgu cümlesi optimizasyon yöntemleri bulunmaktadır:
Öncelikle, veri hacmi büyük olduğunda, tüm tabloyu taramadan kaçınmalı ve veri alımını büyük ölçüde hızlandırabilecek yer ve sırayla ilgili sütunlar üzerine indeksler oluşturmayı düşünmelisiniz. Ancak, indekslemenin işe yaramadığı bazı durumlar vardır:
1. Where cümlesinde != veya <> operatörlerini kullanmaktan kaçınmaya çalışın, aksi takdirde motor indeks kullanımını bırakıp tam tablo taraması yapar.
2. Where cümlesinde olan alanlarda null değer yargısından kaçınmaya çalışın, aksi takdirde motor indeks kullanımını bırakır ve tam tablo taraması yapar, örneğin:
T bölümünden ID seçin, burada num null
Varsayılan değeri 0 olarak num üzerinde ayarlayabilir, tablodaki num sütununda null değer olmadığından emin olabilir ve ardından şöyle sorgulayabilirsin:
T'den ID seçin, burada num=0
3. Koşulları birleştirmek için where cümlesinde OR kullanmaktan kaçının, aksi takdirde motor indeks kullanımını bırakır ve tam bir tablo taraması yapar, örneğin:
T'den ID seçin, burada num=10 veya num=20
Böyle sorgu sorgulayabilirsiniz:
T'den ID seçin burada num=10
Birleşme hepsi
T bölümünden ID seçin burada num=20
4. Aşağıdaki sorgu da tam bir tablo taramasına yol açar:
T'den ID seç, burada ad gibi '%abc%'
Verimliliği artırmak için tam metin aramayı düşünün.
5. İçeri ve Not de dikkatli kullanılmalıdır, aksi takdirde tam tablo taramasına yol açar, örneğin:
T ile ID'yi seç, burada num in(1,2,3)
Sürekli değerler için, eğer between kullanabiliyorsanız, içinde kullanmayın:
T üzerinden ID seçin, burada num 1 ile 3 arasında
6. Where cümlesinde parametreyi kullanırsanız, tam tablo da taranır. SQL yalnızca yerel değişkenleri çalışma zamanında çözer, ancak optimizator erişim planlarının seçimini çalışma zamanına erteleyemez; Derleme sırasında seçilmelidir. Ancak, derleme sırasında bir erişim planı oluşturulursa, değişkenin değeri hâlâ bilinmez ve bu nedenle endeks seçimi için giriş öğesi olarak kullanılamaz. Aşağıdaki ifadeler tam olarak taranacaktır:
T bölümünden ID seçin, burada num=@num
Sorguyu bir indeks kullanmaya zorlayabilirsiniz:
T ile (index(index(index name)) arasından id seçin, burada num=@num
7. Where cümlesinde alanları ifade etmekten kaçının; bu da motorun indeks kullanımını bırakıp tam tablo taraması yapmasına neden olur. Örneğin:
T bölümünden ID seçin, burada num/2=100
şu şekilde değiştirilmelidir:
T'den ID seçin burada num=100*2
8. Where cümlesindeki alanlarda fonksiyon işlemleri yapmaktan kaçının; bu da motorun indeksleri bırakıp tam tablo taraması yapmasına neden olur. Örneğin:
T'den id seçin, burada substring(name,1,3)='abc' – ABC ile başlayan Name ID
T'den ID seçin, burada datediff(day,createdate,'2005-11-30′)=0–'2005-11-30′ oluşturulan id
şu şekilde değiştirilmelidir:
T'den ID seç, burada ad 'abc%' gibi
T üzerinden ID seç burada createdate>='2005-11-30′ ve createdate<'2005-12-1'��
9. "=" where cümlesinde solundaki fonksiyonlar, aritmetik işlemler veya diğer ifade işlemleri yapmayın, aksi takdirde sistem indeksi doğru kullanamayabilir.
10. Bir indeks alanı koşul olarak kullanılırken, eğer indeks bileşik bir indeksse, sistemin indeks kullanmasını sağlamak için indeksin ilk alanı koşul olarak kullanılmalıdır, aksi takdirde indeks kullanılmaz ve alanların sırası mümkün olduğunca indeks sırasıyla tutarlı olmalıdır.
11. Boş bir tablo yapısı oluşturmak gibi anlamsız sorgular yazmayın:
T'den #t'ye col1,col2'yi seçin, burada 1=0
Bu tür kod herhangi bir sonuç kümesi döndürmez, ancak sistem kaynaklarını tüketir, bu yüzden şöyle bir şekilde değiştirilmelidir:
tablo oluştur #t(...)
12. Çoğu zaman mevcut olanların içinde kullanmak iyi bir tercih olur:
Num'u a'dan Num'u seç (Num'u B'den Seç)
Yerine aşağıdaki ifadeyi ekleyin:
Var olan A'dan NUM seçin (B'den 1'i seçin, burada num=a.num)
Bir endeks oluştururken dikkat edilmesi gereken şeyler:
1. Tüm indeksler sorgular için geçerli değildir, SQL sorguyu optimize etmek için tablodaki verilere dayanır; indeks sütununda çok fazla veri çoğaltması varsa, SQL sorguları indeksi kullanmayabilir; örneğin bir tabloda cinsiyet, erkek, kadın alanları neredeyse yarısı bulunur, o zaman indeks cinsiyet üzerine kurulu olsa bile sorgu verimliliğinde rol oynamaz.
2. Ne kadar çok endeks olmazsa, indeks ilgili seçimin verimliliğini kesinlikle artırabilir, ancak ekleme ve güncelleme verimliliğini de azaltır; çünkü indeks eklenirken veya güncellenirken yeniden oluşturulabilir, bu yüzden bir indeksin nasıl oluşturulacağı özel duruma bağlı olarak dikkatlice düşünülmelidir. Bir tabloda 6'dan fazla indeks olmaması en iyisidir ve eğer çok fazlaysa, nadir kullanılan bazı sütunlarda indeks oluşturmanın gerekli olup olmadığını düşünün.
3. Kümelenmiş indeks veri sütunlarını mümkün olduğunca güncellemekten kaçının, çünkü kümelenmiş indeksli veri sütunlarının sırası, tablo kayıtlarının fiziksel depolama sırasıdır ve sütun değeri değiştiğinde, tüm tablo kayıtlarının sırasının ayarlanmasına yol açar ve bu da önemli kaynaklar tüketir. Uygulama sistemi kümelenmiş indeks sütunlarını sık sık güncellemesi gerekiyorsa, indeksin kümelenmiş bir indeks olarak oluşturulup oluşturulmaması gerektiğini düşünmesi gerekir.
Dikkat edilmesi gereken diğer noktalar:
1. Sayısal alanlar kullanmaya çalışın ve sadece karakter olarak sayısal bilgi içeren alanlar tasarlamayın; bu da sorguların ve bağlantıların performansını azaltır ve depolama yükünü artırır. Bunun nedeni, motorun sorgular ve birleştirmeler işlenirken dizide her karakteri teker tek karşılaştırması, sayısal tiplerde ise sadece bir kez karşılaştırılması yeterlidir.
2. Hiçbir yerde *'den seç'i kullanmayın, "*" yerine belirli bir alan listesi ekleyin ve kullanılmayan alanları geri göndermeyin.
3. Geçici tablolar yerine tablo değişkenleri kullanmaya çalışın. Tablo değişkeni büyük miktarda veri içeriyorsa, indeksin çok sınırlı olduğunu (sadece birincil anahtar indeks) unutmayın.
4. Sistem tablosu kaynaklarının tüketimini azaltmak için geçici tablolar oluşturmaktan ve silmekten sık kaçının.
5. Geçici tablolar kullanılamaz değildir ve uygun şekilde kullanmak, örneğin yaygın kullanılan bir tabloda büyük bir tabloya veya veri setine tekrar tekrar referans vermeniz gerektiğinde bazı rutinleri daha etkili hale getirebilir. Ancak, tek seferlik etkinlikler için en iyisi bir dışa aktarma tablosu kullanmaktır.
6. Geçici bir tablo oluştururken, aynı anda eklenen veri miktarı büyükse, çok sayıda logun hız artmasını önlemek için create table yerine select into kullanabilirsiniz; Veri miktarı büyük değilse, sistem tablosunun kaynaklarını kolaylaştırmak için önce tablo oluşturup sonra eklemelisiniz.
7. Geçici bir tablo kullanılıyorsa, saklanan prosedürün sonunda tüm geçici tabloları açıkça sildiğinizden emin olun, önce tabloyu kısaltın, sonra tabloyu kaldırın; böylece sistem tablosunun uzun bir kilitlenmesi önlenir.
8. İmleci kullanmaktan kaçınmaya çalışın, çünkü imlecin verimliliği düşük, eğer imlecin işlettiği veri 10.000 satırı atarsa, yeniden yazmayı düşünmelisiniz.
9. İmleç tabanlı yöntemi veya geçici tablo yöntemini kullanmadan önce, önce problemi çözmek için küme tabanlı çözümler aramalısınız ve küme tabanlı yöntem genellikle daha etkilidir.
10. Geçici tablolar gibi, imleç kullanılamaz değildir. Küçük veri kümeleri için FAST_FORWARD imleci kullanmak, özellikle ihtiyacınız olan veriyi almak için birkaç tabloya başvurmanız gerekiyorsa, diğer satır satır işleme yöntemlerinden genellikle daha iyidir. Sonuç kümesinde "total" içeren rutinler genellikle imleciyle yürütülenlerden daha hızlıdır. Geliştirme süresi izin verirse, hem imleç tabanlı hem de küme tabanlı yöntemler hangisinin daha iyi çalıştığını görmek için denenebilir.
11. Tüm depolanmış prosedürlerin ve tetikleyicilerin başında SET NOCOUNT ON'u, sonunda ise SET NOCOUNT ayarlan. Depolanan prosedürün ve tetikleyicinin her ifadesi yürütüldükten sonra istemciye DONE_IN_PROC mesaj göndermeye gerek yoktur.
12. Büyük verileri müşteriye geri göndermekten kaçınmaya çalışın; veri hacmi çok büyükse, ilgili talebin makul olup olmadığını düşünmelisiniz.
13. Büyük işlem işlemlerinden kaçınmaya çalışın ve sistemin eşzamanlılık yeteneğini geliştirin.
|
Yayınlandı 11.05.2018 13:57:06
|
|
|
Yayınlandı 17.05.2018 10:12:27