Kardinalite Tahmini (SQL Server)

Şunlar için geçerlidir:SQL ServerAzure SQL VeritabanıAzure SQL Yönetilen ÖrneğiMicrosoft Fabric'te SQL veritabanı

SQL Server Sorgu İyileştiricisi, maliyet tabanlı bir Sorgu İyileştiricidir. Bu, yürütülecek en düşük tahmini işleme maliyetine sahip sorgu planlarını seçtiği anlamına gelir. Sorgu İyileştiricisi, bir sorgu planını yürütmenin maliyetini iki ana faktöre göre belirler:

• Bir sorgu planının her düzeyinde işlenen ve planın kardinalitesi olarak adlandırılan toplam satır sayısı.
• Sorguda kullanılan işleçler tarafından dikte edilen algoritmanın maliyet modeli.

İlk faktör olan kardinalite, ikinci faktör olan maliyet modelinin giriş parametresi olarak kullanılır. Bu nedenle, iyileştirilmiş kardinalite daha iyi tahmini maliyetlere ve buna karşılık daha hızlı yürütme planlarına yol açar.

SQL Server'daki kardinalite tahmini (CE), öncelikle dizinler veya istatistikler oluşturulduğunda el ile veya otomatik olarak oluşturulan histogramlardan türetilir. Bazen SQL Server, kardinaliteyi belirlemek için kısıtlama bilgilerini ve sorguların mantıksal yeniden yazmalarını da kullanır.

Aşağıdaki durumlarda SQL Server kardinaliteleri doğru şekilde hesaplayamaz. Bu, yetersiz sorgu planlarına neden olabilecek yanlış maliyet hesaplamalarına neden olur. Sorgularda bu yapılardan kaçınmak sorgu performansını artırabilir. Bazen alternatif sorgu formülasyonları veya diğer ölçüler mümkündür ve bunlar şunlara işaret edilir:

• Aynı tablonun farklı sütunları arasında karşılaştırma işleçleri kullanan koşula sahip sorgular.
• İşleçleri kullanan koşula sahip sorgular ve aşağıdakilerden herhangi biri doğrudur:
  • İşleçlerin her iki tarafında yer alan sütunlarda istatistik yoktur.
  • İstatistiklerdeki değerlerin dağılımı tekdüzen değildir, ancak sorgu son derece seçmeli bir değer kümesi arar. Operatör eşitlik (=) operatöründen başka bir şeyse, bu durum özellikle geçerli olabilir.
  • Öncül, eşit değil (!=) karşılaştırma işlecini veya NOT mantıksal işlecini kullanır.
• Bağımsız değişkeni sabit bir değer olmayan SQL Server yerleşik işlevlerinden herhangi birini veya skaler değerli, kullanıcı tanımlı bir işlevi kullanan sorgular.
• Aritmetik veya dize birleştirme işleçleri aracılığıyla sütunları birleştirmeyi içeren sorgular.
• Sorgu derlendiğinde ve iyileştirildiğinde değerleri bilinmeyen değişkenleri karşılaştıran sorgular.

Bu makalede, sisteminiz için en iyi CE yapılandırmasını nasıl değerlendirebileceğiniz ve seçebileceğiniz gösterilmektedir. Çoğu sistem en doğru olduğu için en son CE'den yararlanan sistemlerdir. CE, sorgunuzun büyük olasılıkla kaç satır döndüreceğini tahmin eder. Kardinalite tahmini, Sorgu İyileştiricisi tarafından en uygun sorgu planını oluşturmak için kullanılır. Daha doğru tahminlerle, Sorgu İyileştiricisi genellikle daha iyi bir sorgu planı oluşturmak için daha iyi bir iş yapabilir.

Uygulama sisteminizde, sürümler boyunca CE'deki değişiklikler nedeniyle planı daha yavaş bir plana değiştirilen önemli bir sorgu olabilir. CE sorunları nedeniyle daha yavaş performans gösteren bir sorguyu tanımlamaya yönelik teknikler ve araçlara sahipsiniz. Ayrıca, performans sorunlarını gidermeye yönelik seçenekleriniz de vardır.

CE'nin sürümleri

1998'de, CE'nin önemli bir güncelleştirmesi, uyumluluk düzeyinin 70 olduğu SQL Server 7.0'ın bir parçasıydı. CE modelinin bu sürümü dört temel varsayıma göre ayarlanır:

• Bağımsızlık: Bağıntı bilgileri mevcut ve kullanılabilir olmadığı sürece, farklı sütunlardaki veri dağıtımlarının birbirinden bağımsız olduğu varsayılır.

• Düzgünlüğü: Ayrı değerler eşit aralıklı ve hepsinin aynı frekansa sahip olması. Daha kesin olarak, her histogram adımında ayrı değerler eşit olarak yayılır ve her değerin sıklığı aynı olur.

• Kapsama (Basit): Kullanıcılar var olan verileri sorgular. Örneğin, iki tablo arasındaki eşitlik birleşimi için birleşim seçiciliğini tahmin etmek için histogramları birleştirmeden önce her giriş histogramında seçicilik¹ koşulunu dikkate alın.

• Eklenmesi: filtre koşullarında, Column = Constantsabitin ilişkili sütun için gerçekten var olduğu varsayılır. Eğer karşılık gelen bir histogram adımı boş değilse, adımın farklı değerlerinden birinin koşuldaki değerle eşleştiği varsayılır.

  ¹ Koşulu karşılayan satır sayısı.

Sonraki güncelleştirmeler SQL Server 2014 (12.x) ile başladı, yani uyumluluk düzeyleri 120 ve üzeri. 120 ve üzeri düzeyler için CE güncelleştirmeleri, modern veri ambarı ve OLTP iş yükleri üzerinde iyi çalışan güncelleştirilmiş varsayımları ve algoritmaları içerir. CE 70 varsayımlarından, CE 120'den başlayarak aşağıdaki model varsayımları değiştirildi:

• BağımsızlıkBağıntıya dönüşür: Farklı sütun değerlerinin birleşimi mutlaka bağımsız değildir. Bu daha gerçek zamanlı veri sorgulamaya benzeyebilir.
• Basit Kapsama, Temel Kapsama olur: Kullanıcılar var olmayan verileri sorgulayabilir. Örneğin, iki tablo arasındaki eşitlik birleşimi için birleşim seçiciliğini tahmin etmek için temel tablo histogramlarını kullanırız ve ardından koşul seçiciliğini dikkate alırız.

CE sürümünü değerlendirmek için Sorgu Deposu'nı kullanma

SQL Server 2016(13.x) ile başlayarak Sorgu Deposu, sorgularınızın performansını incelemek için kullanışlı bir araçtır. Sorgu Deposu etkinleştirildikten sonra, yürütme planları değişse bile sorgu performansını zaman içinde izlemeye başlar. Yüksek maliyetli veya regresyonlu sorgu performansı için Sorgu Deposu'na bakın. Daha fazla bilgi için bkz. Sorgu Deposu'nı kullanarak performansı izleme.

SQL Server'a yükseltmeye hazırlanıyorsanız veya herhangi bir SQL Server platformunda veritabanı uyumluluk düzeyini yükseltiyorsanız, iki farklı uyumluluk düzeyinde sorgu performansını karşılaştırmaya yardımcı olabilecek Sorgu Ayarlama Yardımcısı'nı kullanarak veritabanlarını yükseltmeyi göz önünde bulundurun.

Important

Sorgu Deposu'un veritabanınız ve iş yükünüz için doğru yapılandırıldığından emin olun. Daha fazla bilgi için bkz. Sorgu Deposu ile iş yüklerini izlemeye yönelik en iyi yöntemler.

CE sürümünü değerlendirmek için genişletilmiş olayları kullanma

Kardinalite tahmin işlemini izlemek için bir diğer seçenek de adlı query_optimizer_estimate_cardinalitygenişletilmiş olayı kullanmaktır. Aşağıdaki Transact-SQL kod örneği SQL Server üzerinde çalışır. Bir .xel dosyasını C:\Temp\ adresine yazar (ancak yolu değiştirebilirsiniz). .xel dosyasını Management Studio'da açtığınızda, ayrıntılı bilgileri kullanıcı dostu bir şekilde görüntülenir.

DROP EVENT SESSION Test_the_CE_qoec_1 ON SERVER;
go

CREATE EVENT SESSION Test_the_CE_qoec_1
ON SERVER
ADD EVENT sqlserver.query_optimizer_estimate_cardinality
 (
 ACTION (sqlserver.sql_text)
  WHERE (
  sql_text LIKE '%yourTable%'
  and sql_text LIKE '%SUM(%'
  )
 )
ADD TARGET package0.asynchronous_file_target
 (SET
  filename = 'c:\temp\xe_qoec_1.xel',
  metadatafile = 'c:\temp\xe_qoec_1.xem'
 );
GO

ALTER EVENT SESSION Test_the_CE_qoec_1
ON SERVER
STATE = START;  --STOP;
GO

Note

Olay sqlserver.query_optimizer_estimate_cardinality Azure SQL Veritabanı için kullanılamaz.

SQL Veritabanı için uyarlanmış genişletilmiş olaylar hakkında bilgi için bkz. SQL Veritabanı'nda genişletilmiş olaylar.

CE sürümünü değerlendirme adımları

En önemli sorgularınızdan herhangi birinin en son CE altında daha kötü performans gösterip göstermediğini değerlendirmek için kullanabileceğiniz adımlar aşağıdadır. Adımlardan bazıları, önceki bölümde sunulan bir kod örneği çalıştırılarak gerçekleştirilir.

1. SQL Server Management Studio'yu (SSMS) açın. SQL Server veritabanınızın kullanılabilir en yüksek uyumluluk düzeyine ayarlandığından emin olun.

2. Aşağıdaki ön adımları gerçekleştirin:

   1. SQL Server Management Studio'yu (SSMS) açın.

   2. SQL Server veritabanınızın kullanılabilir en yüksek uyumluluk düzeyine ayarlandığından emin olmak için Transact-SQL çalıştırın.

   3. Veritabanınızın yapılandırmasının LEGACY_CARDINALITY_ESTIMATION açık OFFolduğundan emin olun.

   4. Sorgu Depo'nuzu temizleyin. Veritabanınızda Sorgu Deposu'nda ON olduğundan emin olun.

   5. Komutu çalıştırın: SET NOCOUNT OFF;

3. Komutu çalıştırın: SET STATISTICS XML ON;

4. Önemli sorgunuzu çalıştırın.

5. Sonuçlar bölmesindeki İletiler sekmesinde, etkilenen gerçek satır sayısını not edin.

6. Sonuçlar sekmesindeki sonuçlar bölmesinde, istatistikleri XML biçiminde içeren hücreye çift tıklayın. Grafik sorgu planı görüntülenir.

7. Grafik sorgu planındaki ilk kutuya sağ tıklayın ve özellikler'i seçin.

8. Daha sonra farklı bir yapılandırmayla karşılaştırmak için aşağıdaki özelliklerin değerlerine dikkat edin:

   • CardinalityEstimationModelVersion.

   • Tahmini Satır Sayısı.

   • Tahmini G/Ç Maliyeti ve satır sayısı tahminleri yerine gerçek performansı içeren birkaç benzer Tahmini özellik.

   • Mantıksal İşlem ve Fiziksel İşlem. Paralellik iyi bir değerdir.

   • Gerçek Yürütme Modu. Batch, Satır'dan daha iyi bir seçenektir.

9. Tahmini satır sayısını gerçek satır sayısıyla karşılaştırın. CE'nin doğruluk oranı %1 mi (yüksek veya düşük), yoksa %10 mu yanlış?

10. Çalıştırın: SET STATISTICS XML OFF;

11. Veritabanınızın uyumluluk düzeyini bir düzey azaltmak için Transact-SQL çalıştırın (örneğin, 130'dan 120'ye kadar).

12. Ön adım olmayan tüm adımları yeniden çalıştırın.

13. İki çalıştırmadaki CE özellik değerlerini karşılaştırın.

    • Yanlışlık yüzdesi en yeni CE'nin altında eski CE'den küçük mü?

14. Son olarak, iki çalıştırmadaki çeşitli performans özelliği değerlerini karşılaştırın.

    • Sorgu, iki farklı CE tahmini altında farklı bir plan mı kullanıyor?

    • Sorgunuz en son CE altında daha yavaş çalıştı mı?

    • Sorgunuz, eski CE altında farklı bir yürütme planıyla daha iyi çalışmadığı sürece, muhtemelen en son CE'yi tercih edersiniz.

    • Ancak, sorgunuzun eski CE altında daha hızlı bir planla çalıştığını görüyorsanız, sistemi daha hızlı planı kullanmaya zorlamayı ve CE'yi göz ardı etmeyi düşünün. Bu yolla, her şey için en son CE'yi kullanabilirken, tek tük bir durumda daha hızlı planı koruyabilirsiniz.

En iyi sorgu planını etkinleştirme

CE 120 veya üzeri ile sorgunuz için daha az verimli bir sorgu planı oluşturulduğunu varsayalım. Aşağıda, en büyük kapsamdan en küçüğe doğru sıralanmış daha iyi planı etkinleştirmeniz gereken bazı seçenekler verilmiştir:

• Veritabanı uyumluluk düzeyini tüm veritabanınız için kullanılabilir en son değerden daha düşük bir değere ayarlayabilirsiniz.

  • Örneğin, uyumluluk düzeyinin 110 veya daha düşük olması CE 70'i etkinleştirir, ancak tüm sorguları önceki CE modeline tabi kılar.

  • Ayrıca, daha düşük bir uyumluluk düzeyi ayarlamak, en son sürümler için sorgu iyileştiricisindeki bir dizi iyileştirmeyi de kaçırır ve veritabanındaki tüm sorguları etkiler.

• Veritabanı kapsamlı yapılandırma seçeneğini kullanarak LEGACY_CARDINALITY_ESTIMATION tüm veritabanının eski CE'yi kullanmasını sağlayabilir ve sorgu iyileştiricisindeki diğer geliştirmeleri koruyabilirsiniz.

• Sorgu ipucunu kullanarak LEGACY_CARDINALITY_ESTIMATION tek bir sorgunun eski CE'yi kullanmasını sağlayabilir ve sorgu iyileştiricisindeki diğer geliştirmeleri koruyabilirsiniz.

• Tek bir sorgunun LEGACY_CARDINALITY_ESTIMATION sorguyu değiştirmeden eski CE'yi kullanmasını sağlamak için Sorgu Deposu ipucu özelliği aracılığıyla öğesini zorlayabilirsiniz.

• Sorgu Deposu ile farklı bir planı uygula.

Veritabanı uyumluluk düzeyi

ALTER DATABASE (Transact-SQL) uyumluluk düzeyi için aşağıdaki Transact-SQL kodunu kullanarak veritabanınızın belirli bir düzeyde olduğundan emin olabilirsiniz.

Important

SQL Server ve Azure SQL Veritabanı için veritabanı altyapısı sürüm numaraları birbiriyle karşılaştırılamaz ve bu ayrı ürünlerin iç derleme numaralarıdır. Azure SQL Server için veritabanı altyapısı, SQL Server veritabanı altyapısıyla aynı kod tabanını temel alır. En önemlisi, Azure SQL Veritabanı'ndaki veritabanı altyapısı her zaman en yeni SQL veritabanı altyapısı bitlerine sahiptir. Azure SQL Veritabanı’nın 12. sürümü, SQL Server’ın 15. sürümünden daha yenidir. Kasım 2019 itibarıyla Azure SQL Veritabanı'nda yeni oluşturulan veritabanları için varsayılan uyumluluk düzeyi 150'dir. Microsoft, mevcut veritabanları için Veritabanı Uyumluluk Düzeyini güncelleştirmez. Müşterilerin kendi takdirine bağlı olarak yapması gereken bir işlemdir.

SELECT ServerProperty('ProductVersion');
GO

SELECT d.name, d.compatibility_level
FROM sys.databases AS d
WHERE d.name = 'yourDatabase';
GO

Daha düşük uyumluluk düzeylerinde çalışan önceden var olan veritabanları için, uygulamanın yalnızca daha yüksek bir veritabanı uyumluluk düzeyinde kullanılabilen iyileştirmeleri kullanması gerekmediği sürece, önceki veritabanı uyumluluk düzeyini korumak için geçerli bir yaklaşımdır. Yeni geliştirme çalışmaları için veya mevcut bir uygulama SQL veritabanlarında Akıllı sorgu işleme gibi yeni özelliklerin kullanılmasını gerektirdiğinde ve bazı yeni Transact-SQL'lerde veritabanı uyumluluk düzeyini kullanılabilir en son düzeye yükseltmeyi planlayın. Daha fazla bilgi için bkz . Uyumluluk düzeyleri ve Veritabanı Altyapısı yükseltmeleri.

Caution

Veritabanı uyumluluk düzeyini değiştirmeden önce ALTER DATABASE (Transact-SQL) uyumluluk düzeyini gözden geçirin.

ALTER DATABASE <yourDatabase>
SET COMPATIBILITY_LEVEL = 150;
GO

Uyumluluk düzeyi 120 veya üzeri olan bir SQL Server veritabanı için, 9481 izleme bayrağının etkinleştirilmesi sistemi CE sürüm 70'i kullanmaya zorlar.

Eski kardinalite tahmin aracı

Uyumluluk düzeyi 120 ve üzeri olan bir SQL Server veritabanı için, alter DATABASE SCOPED CONFIGURATION kullanılarak eski kardinalite tahmin aracı (CE sürüm 70) veritabanı düzeyinde etkinleştirilebilir.

ALTER DATABASE SCOPED CONFIGURATION
SET LEGACY_CARDINALITY_ESTIMATION = ON;
GO

SELECT name, value
FROM sys.database_scoped_configurations
WHERE name = 'LEGACY_CARDINALITY_ESTIMATION';
GO

İpucu kullanmak için sorguyu değiştirme

SQL Server 2016 (13.x) SP1'den başlayarak sorguyu Sorgu İpucu'nuUSE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION') kullanacak şekilde değiştirin.

SELECT CustomerId, OrderAddedDate
FROM OrderTable
WHERE OrderAddedDate >= '2016-05-01'
OPTION (USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION'));

Sorgu Deposu ipucu ayarla

Sorgular, Sorgu Deposu ipuçları kullanılarak sorguda değişiklik yapmadan eski kardinalite tahmin aracını kullanmaya zorlanabilir.

1. sorguyu sys.query_store_query_text ve sys.query_store_query Sorgu Deposu katalog görünümlerinde tanımlayın. Örneğin, yürütülen bir sorguyu metin parçasına göre arayın:

   SELECT q.query_id, qt.query_sql_text
   FROM sys.query_store_query_text qt
   INNER JOIN sys.query_store_query q ON
   qt.query_text_id = q.query_text_id
   WHERE query_sql_text like N'%ORDER BY ListingPrice DESC%'
   AND query_sql_text not like N'%query_store%';
   

2. Aşağıdaki örnek, sorguyu değiştirmeden query_id 39 üzerinde eski kardinalite tahmincisini zorlamak için bir Sorgu Deposu ipucu uygular.

   EXEC sys.sp_query_store_set_hints @query_id= 39, @query_hints = N'OPTION(USE HINT(''FORCE_LEGACY_CARDINALITY_ESTIMATION''))';
   

Note

Daha fazla bilgi için bkz. Sorgu Deposu ipuçları (Önizleme). Şu anda bu özellik yalnızca Azure SQL Veritabanı'nda kullanılabilir.

Belirli bir sorgu planını zorunlu kılma

En iyi kontrol için, testiniz sırasında sistemi CE 70 ile oluşturulan planı kullanmaya zorlayabilirsiniz . Tercih ettiğiniz planı sabitledikten sonra tüm veritabanınızı en son uyumluluk düzeyini ve CE'yi kullanacak şekilde ayarlayabilirsiniz. Seçenek daha sonra ayrıntılı olarak açıklanmıştır.

Sorgu Deposu, sistemi belirli bir sorgu planını kullanmaya zorlayabileceğiniz farklı yollar sunar:

• sys.sp_query_store_force_planYürüt.

• SQL Server Management Studio'da (SSMS), Sorgu Deposu düğümünüzü genişletin, En Çok Kaynak Tüketen Düğümler'e sağ tıklayın ve en çok kaynak tüketen düğümleri görüntüle'yi seçin. Ekranda Planı Zorla ve Planı Zorlama etiketli düğmeler gösterilir.

Sorgu Deposu hakkında daha fazla bilgi için bkz. Sorgu Deposu kullanarak performansı izleme.

Kartalite Tahmini sırasında sabit katlama ve ifade değerlendirmesi

Veritabanı Altyapısı, sorgu performansını geliştirmek için bazı sabit ifadeleri erken değerlendirir. Bu, sabit katlama olarak adlandırılır. Sabit, 3, 'ABC', '2005-12-31', 1.0e3 veya 0x12345678 gibi Transact-SQL literali olan bir değişmez değerdir. Daha fazla bilgi için bkz. Sabit Katlama.

Ayrıca, sabit olarak katlanmamış ancak derleme zamanında bağımsız değişkenleri bilinen, bağımsız değişkenlerin parametre mi yoksa sabit mi olduğu bilinen bazı ifadeler, iyileştirme sırasında Sorgu İyileştiricisi'nin parçası olan sonuç kümesi boyutu (kardinalite) tahmin aracı tarafından değerlendirilir. Daha fazla bilgi için bkz. İfade Değerlendirmesi.

En İyi Yöntemler: En iyi sorgu planlarını oluşturmak için sürekli katlama ve derleme zamanı ifadesi değerlendirmesi kullanma

En iyi sorgu planlarını oluşturduğunuzdan emin olmak için sorgular, saklı yordamlar ve toplu işlemler tasarlayarak Sorgu İyileştiricisi'nin veri dağıtımınızla ilgili istatistiklere göre sorgunuzdaki koşulların seçiciliğini doğru şekilde tahmin edebilmesini sağlamak en iyisidir. Aksi takdirde Sorgu İyileştiricisi, seçicilik tahmininde bulunurken varsayılan bir tahmin kullanmalıdır.

Sorgu İyileştiricisi Kardinalite Tahmin Aracı'nın iyi tahminler sağladığından emin olmak için, önce ve AUTO_CREATE_STATISTICS veritabanı AUTO_UPDATE_STATISTICS seçeneklerinin SETON (varsayılan ayar) olduğundan veya sorgu koşulunda başvurulan tüm sütunlarda el ile istatistik oluşturduğunuzdan emin olmanız gerekir. Ardından, sorgularınızdaki koşulları tasarlarken mümkün olduğunda aşağıdakileri yapın:

• Sorgularda yerel değişkenlerin kullanılmasından kaçının. Bunun yerine sorguda parametreleri, değişmez değerleri veya ifadeleri kullanın.

• Parametre içeren bir sorguya eklenmiş işleçlerin ve işlevlerin kullanımını Kardinalite Tahmini için İfade Değerlendirmesi Compile-Time altında listelenenlerle sınırlayın.

• Sorgunuzun koşulundaki yalnızca sabit ifadelerin sabit katlanabilir olduğundan veya derleme zamanında değerlendirilebildiğinden emin olun.

• Sorguda kullanılacak bir ifadeyi değerlendirmek için yerel bir değişken kullanmanız gerekiyorsa, bunu sorgudan farklı bir kapsamda değerlendirmeyi göz önünde bulundurun. Örneğin, aşağıdaki seçeneklerden birini gerçekleştirmek yararlı olabilir:

  • Değişkenin değerini değerlendirmek istediğiniz sorguyu içeren saklı yordama geçirin ve sorgunun yerel değişken yerine yordam parametresini kullanmasını sağlayın.

  • Yerel değişkenin değerine göre kısmen sorgu içeren bir dize oluşturun ve ardından dinamik SQL (EXEC veya tercihen sp_executesql) kullanarak dizeyi yürütür.

  • Sorguyu parametreleştirin ve sp_executesql kullanarak yürütün, değişkenin değerini sorguya parametre olarak geçirin.

CE geliştirme örnekleri

Bu bölümde, son sürümlerde CE'de uygulanan geliştirmelerden yararlanan örnek sorgular açıklanmaktadır. Bu, belirli bir eylemi gerektirmeyen arka plan bilgisidir.

Örnek A. CE, en yüksek değerin istatistiklerin en son toplandığından daha yüksek olabileceğini anlar

Varsayalım ki istatistikler en son OrderTable tarihinde 2016-04-30 için toplandıysa ve en yüksek OrderAddedDate değeri 2016-04-30 olmuşsa. CE 120 (ve üzeri sürüm), OrderTable verilere sahip olan içindeki sütunların istatistikler tarafından kaydedilen en yüksek değerden daha büyük değerlere sahip olabileceğini anlar. Bu anlayış, aşağıdaki gibi Transact-SQL SELECT deyimleri için sorgu planını geliştirir.

SELECT CustomerId, OrderAddedDate
FROM OrderTable
WHERE OrderAddedDate >= '2016-05-01';

Örnek B. CE, aynı tablodaki filtrelenmiş önkoşulların genellikle bağıntılı olduğunu anlar

Aşağıda SELECT ve Modelüzerinde ModelVariant filtrelenmiş koşullarını görüyoruz. Xbox'ın One adlı bir varyantı olduğu göz önünde bulundurulduğunda Model ,'Xbox' olduğunda 'One' olma ihtimalinin ModelVariant olduğunu sezgisel olarak anlıyoruz.

CE 120'den başlayarak, SQL Server aynı tablodaki ModelModelVariantiki sütun ve arasında bir bağıntı olabileceğini anlar. CE, sorgu tarafından kaç satır döndürüleceğini daha doğru bir şekilde tahmin eder ve sorgu iyileştiricisi daha uygun bir plan oluşturur.

SELECT Model, Purchase_Price
FROM dbo.Hardware
WHERE Model = 'Xbox' AND
ModelVariant = 'Series X';

Örnek C. CE artık farklı tablolardan filtrelenmiş koşul arasında herhangi bir bağıntı olmadığını varsayar

Modern iş yükleri ve gerçek iş verileriyle ilgili kapsamlı yeni araştırmalar, farklı tablolardaki koşul filtrelerinin genellikle birbiriyle bağıntılı olmadığını ortaya koyuyor. Aşağıdaki sorguda CE, ile s.typearasında r.date bir bağıntı olmadığını varsayar. Bu nedenle CE, döndürülen satır sayısı için daha düşük bir tahminde bulunur.

SELECT s.ticket, s.customer, r.store
FROM dbo.Sales AS s
CROSS JOIN dbo.Returns AS r
WHERE s.ticket = r.ticket AND
s.type = 'toy' AND
r.date = '2016-05-11';

İlgili içerik

• Kardinalite tahmini (CE) geri bildirimi
• Performans İzleme ve Ayarlama
• SQL Server 2014 Kardinalite Tahmin Aracı ile Sorgu Planlarınızı İyi
• Sorgu ipuçları (Transact-SQL)
• USE HINT Sorgu İpuçları
• Sorgu Ayarlama Yardımcısı'nı kullanarak veritabanlarını yükseltme
• Sorgu Deposu’nu kullanarak performansı izleme
• Sorgu işleme mimarisi kılavuzu
• Sorgu Deposu İpuçları
• SQL veritabanlarında akıllı sorgu işleme
• DBCC TRACEON (Transact-SQL) ile izleme bayrakları ayarlama
• sys.query_store_query_hints