Parametreye Duyarlı Plan Optimizasyonu

Şunlar için geçerlidir: SQL Server 2022 (16.x) ve sonraki sürümleri Azure SQL Veritabanı Azure SQL Yönetilen Örneği Microsoft Fabric'teki SQL veritabanı

Parametre Duyarlı Plan (PSP) iyileştirmesi, Akıllı sorgu işleme özellik ailesinin bir parçasıdır. Parametreli sorgu için tek bir önbelleğe alınmış planın tüm olası gelen parametre değerleri için en uygun olmadığı senaryoyu ele alır. Tekdüzen olmayan veri dağıtımlarında bu durum geçerlidir. Daha fazla bilgi için bkz . Parametre Duyarlılığı ve Parametreleri ve Yürütme Planı Yeniden Kullanımı.

Bu sorun senaryosu için mevcut geçici çözümler hakkında daha fazla bilgi için bkz:

PSP iyileştirmesi, tek bir parametreli deyim için birden çok etkin önbelleğe alınmış planı otomatik olarak etkinleştirir. Önbelleğe alınmış yürütme planları, müşteri tarafından sağlanan çalışma zamanı parametre değerlerine göre farklı veri boyutlarını barındırır.

Parametreleştirmeyi anlama

SQL Server Veritabanı Altyapısı'nda, Transact-SQL (T-SQL) deyimlerinde parametrelerin veya parametre işaretçilerinin kullanılması, ilişkisel altyapının yeni T-SQL deyimlerini mevcut, daha önce derlenmiş yürütme planlarıyla eşleştirme ve plan yeniden kullanımını yükseltme becerisini artırır. Daha fazla bilgi için bkz. Basit Parametreleştirme.

Ayrıca, veritabanındaki tüm SELECT, INSERT, UPDATEve DELETE deyimlerinin belirli sınırlamalara tabi olarak parametrelendirildiğini belirterek SQL Server'ın varsayılan basit parametreleştirme davranışını geçersiz kılabilirsiniz. Daha fazla bilgi için bkz . Zorlamalı Parametreleştirme.

PSP iyileştirme uygulaması

İlk derleme sırasında, sütun istatistikleri histogramları tekdüzen olmayan dağılımları tanımlar ve tüm kullanılabilir koşullardan en fazla üç tane olmak üzere en riskli parametreli koşullarını değerlendirir. Başka bir deyişle, aynı sorgudaki birden çok koşul ölçütleri karşılıyorsa PSP iyileştirmesi ilk üç koşulu seçer. PSP özelliği, plan önbelleğini ve Sorgu Deposu'nun (Sorgu Deposu etkinse) çok fazla planla şişirilmesinden kaçınmak için değerlendirilen koşul sayısını sınırlar.

Uygun planlar için ilk derleme, dağıtıcı ifadesi olarak adlandırılan PSP iyileştirme mantığını içeren bir dağıtıcı planı oluşturur. Dağıtıcı planı, kardinalite aralığı sınır değerleri önermelerine dayalı sorgu varyantları ile eşleştirilir.

Terminology

Dispatcher ifadesi

Çalışma zamanı parametre değerlerine göre koşul kardinalitesini değerlendirir ve yürütmeyi farklı sorgu değişkenlerine yönlendirir.

Dağıtıcı planı

Dağıtıcı ifadesini içeren bir plan özgün sorgu için önbelleğe alınır. Dağıtıcı planı temelde özellik tarafından seçilen ve birkaç ek ayrıntı içeren bir koşul koleksiyonudur. Seçilen her koşul için dağıtıcı planına dahil edilen ayrıntılardan bazıları yüksek ve düşük sınır değerleridir. Bu değerler parametre değerlerini farklı demetlere veya aralıklara bölmek için kullanılır. Dağıtıcı planı, sınır değerlerini hesaplamak için kullanılan istatistikleri de içerir.

Sorgu değişkeni

Dağıtıcı planı, çalışma zamanı parametre değerlerine göre koşul kardinalitesini değerlendirirken, bu değerleri demetler ve derlemek ve yürütmek için ayrı alt sorgular oluşturur. Bu çocuk sorgulara sorgu varyantları adı verilir. Sorgu değişkenlerinin plan önbelleğinde ve Sorgu Deposu'nda kendi planları vardır.

Predikat kardinalite aralığı

Çalışma zamanında, her koşulun kardinalitesi çalışma zamanı parametre değerlerine göre değerlendirilir. Dağıtıcı, kardinalite değerlerini derleme zamanında üç kapsamlı öncül kardinalite aralığına ayırır. Örneğin, PSP iyileştirme özelliği aşağıdaki diyagramda gösterildiği gibi düşük, orta ve yüksek kardinalite aralıklarını temsil eden üç aralık oluşturabilir.

Başka bir deyişle, parametreli bir sorgu başlangıçta derlendiğinde PSP iyileştirme özelliği dağıtıcı planı olarak bilinen bir kabuk planı oluşturur. Dağıtıcı ifadesi, parametrelerin çalışma zamanı değerlerine göre sorguları sorgu çeşitlemelerine ayıran mantığa sahiptir. Gerçek yürütme başladığında dağıtıcı iki adım gerçekleştirir:

Dağıtıcı, kardinalite aralığını hesaplamak için verilen parametre kümesi üzerinde dağıtıcı ifadesini değerlendirir.
Dağıtıcı, bu aralıkları belirli sorgu ifadesi varyantlarıyla eşleştirir ve bu varyantları derleyip yürütür. PsP iyileştirme özelliği, birden çok sorgu değişkenine sahip olma özelliği sayesinde tek bir sorgu için birden çok plana sahip olmayı sağlar.

Kardinalite aralığı sınırları, bir dağıtım planının ShowPlan XML'i içinde görülebilir:

<Dispatcher>
  <ParameterSensitivePredicate LowBoundary="100" HighBoundary="1000000">
    <StatisticsInfo Database="[PropertyMLS]" Schema="[dbo]" Table="[Property]" Statistics="[NCI_Property_AgentId]" ModificationCount="0" SamplingPercent="100" LastUpdate="2019-09-07T15:32:16.89" />
    <Predicate>
      <ScalarOperator ScalarString="[PropertyMLS].[dbo].[Property].[AgentId]=[@AgentId]">
        <Compare CompareOp="EQ">
          <ScalarOperator>
            <Identifier>
              <ColumnReference Database="[PropertyMLS]" Schema="[dbo]" Table="[Property]" Column="AgentId" />
            </Identifier>
          </ScalarOperator>
          <ScalarOperator>
            <Identifier>
              <ColumnReference Column="@AgentId" />
            </Identifier>
          </ScalarOperator>
        </Compare>
      </ScalarOperator>
    </Predicate>
  </ParameterSensitivePredicate>
</Dispatcher>

PSP optimizasyonu tarafından üretilen bir ipucu, sorgu varyantının ShowPlan XML'inde SQL ifadesine eklenir. İpucu doğrudan kullanılamaz ve el ile eklenirse ayrıştırılmaz . İpucu aşağıdaki öğeleri içerir:

option ( PLAN PER VALUE ( ObjectID = (int), QueryVariantID = (int), predicate_range ( [databaseName].[ schemaName]. [tableName]. [columnName] = @paramName, lowBoundaryValue, highBoundaryValue ) ) )

ObjectID , geçerli deyimin parçası olduğu modülden (saklı yordam, işlev, tetikleyici) gelir; deyiminin bir modülden oluşturulduğu varsayımıyla. Deyim, dinamik veya ad-hoc SQL'in (yani, sp_executesql) sonucuysa, ObjectID öğesi 0 ile eşittir.
QueryVariantID kabaca PSP iyileştirmesinin seçtiği tüm koşullarda aralıkların birleşimine eşdeğerdir. Örneğin, bir sorguda PSP için uygun iki koşul varsa ve her koşulda üç aralık varsa, 1-9 numaralı dokuz sorgu değişken aralığı olacaktır.
koşul aralığı , dağıtıcı ifadesinden oluşturulan önceden belirtilen kardinalite aralığı bilgileridir.

Bir sorgu varyantının ShowPlan XML'si içinde (Dispatcher öğesi içinde):

<Batch>
  <Statements>
    <StmtSimple StatementText="SELECT PropertyId,&#xD;&#xA;       AgentId,&#xD;&#xA;       MLSLinkId,&#xD;&#xA;       ListingPrice,&#xD;&#xA;       ZipCode,&#xD;&#xA;       Bedrooms,&#xD;&#xA;       Bathrooms&#xD;&#xA;FROM dbo.Property&#xD;&#xA;WHERE AgentId = @AgentId&#xD;&#xA;ORDER BY ListingPrice DESC option (PLAN PER VALUE(ObjectID = 613577224, QueryVariantID = 1, predicate_range([PropertyMLS].[dbo].[Property].[AgentId] = @AgentId, 100.0, 1000000.0)))" StatementId="1" StatementCompId="2" StatementType="SELECT" StatementSqlHandle="0x090085E4372DFC69BB9E7EBA421561DE8E1E0000000000000000000000000000000000000000000000000000" DatabaseContextSettingsId="1" ParentObjectId="0" StatementParameterizationType="1" RetrievedFromCache="false" StatementSubTreeCost="0.021738" StatementEstRows="3" SecurityPolicyApplied="false" StatementOptmLevel="FULL" QueryHash="0x476167A000F589CD" QueryPlanHash="0xDE982107B7C28AAE" StatementOptmEarlyAbortReason="GoodEnoughPlanFound" CardinalityEstimationModelVersion="160">
      <StatementSetOptions QUOTED_IDENTIFIER="true" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" NUMERIC_ROUNDABORT="false" />

      <Dispatcher>
        <ParameterSensitivePredicate LowBoundary="100" HighBoundary="1e+06">
          <StatisticsInfo LastUpdate="2019-09-07T15:32:16.89" ModificationCount="0" SamplingPercent="100" Statistics="[NCI_Property_AgentId]" Table="[Property]" Schema="[dbo]" Database="[PropertyMLS]" />
          <Predicate>
            <ScalarOperator ScalarString="[PropertyMLS].[dbo].[Property].[AgentId]=[@AgentId]">
              <Compare CompareOp="EQ">
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Database="[PropertyMLS]" Schema="[dbo]" Table="[Property]" Column="AgentId" />
                  </Identifier>
                </ScalarOperator>
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Column="@AgentId" />
                  </Identifier>
                </ScalarOperator>
              </Compare>
            </ScalarOperator>
          </Predicate>
        </ParameterSensitivePredicate>
      </Dispatcher>

    </StmtSimple>
  </Statements>
</Batch>

Remarks

SQL Server 2025 (17.x) ve veritabanı uyumluluğu 170'den başlayarak PSP iyileştirmesi aşağıdaki dört geliştirmeyi içerir:
- DELETE, INSERT, MERGE ve UPDATE gibi veri işleme dili Veri İşleme Dili (DML) deyimleri için destek.
- tempdb için genişletilmiş destek.
- Aynı tabloda birden çok uygun koşulun bulunduğu senaryolarda dikkate alınacak ek noktalar.
- SQL Server 2025 (17.x) ve veritabanı uyumluluğu 170'teki değişikliklerden önce, interesting_predicate_count, max_skewness, psp_optimization_supported ve query_type alanlarını içeren genişletilmiş olayda değişiklikler yapılmıştır. Ancak artık interesting_predicate_count, interesting_predicate_details, psp_optimization_supported ve query_type alanlarını ekleyin. Daha fazla bilgi için Genişletilmiş Olaylar bölümüne bakın.
PSP iyileştirme özelliği şu anda yalnızca eşitlik önkoşullarıyla çalışır.
Önemli veri dağıtım değişiklikleri varsa dağıtıcı planları otomatik olarak yeniden oluşturulur. Sorgu değişken planları, diğer sorgu planı türlerde olduğu gibi, varsayılan yeniden derleme olaylarına tabi olarak gerektiğinde bağımsız olarak yeniden derler. Yeniden derleme hakkında daha fazla bilgi için bkz. Yürütme Planlarını Yeniden Derleme.
sys.query_store_plan Sorgu Deposu sistem kataloğu görünümü, normal derlenmiş plan, dağıtıcı planı ve sorgu değişken planı arasında ayrım yapmak için değiştirildi. Yeni Sorgu Deposu sistem kataloğu görünümü sys.query_store_query_variant, özgün parametreli sorgular (üst sorgular olarak da bilinir), dağıtıcı planları ve çocuk sorgu değişkenleri arasındaki ebeveyn-çocuk ilişkileri hakkında bilgi içerir.
Aynı tablonun parçası olan birden çok koşul olduğunda, PSP iyileştirmesi temel istatistik histogramına göre en fazla veri dengesizliği olan koşulu seçer. Örneğin, SELECT * FROM table WHERE column1 = @predicate1 AND column2 = @predicate2 ile, column1 = @predicate1 ve column2 = @predicate2 aynı tablodan olduğu için, table1 özelliği yalnızca en çarpık koşulu değerlendirecektir. Ancak, örnek sorgu gibi UNIONbir işleç içeriyorsa PSP birden fazla koşulu değerlendirir. Örneğin, bir sorgu SELECT * FROM table WHERE column1 = @predicate UNION SELECT * FROM table WHERE column1 = @predicate ile benzer özelliklere sahipse, PSP bu durumda en fazla iki öncül seçer, çünkü sistem bu senaryoyu öncüllerin iki farklı tablo gibi olduğu biçimde ele alır. Tablo diğer adları aracılığıyla kendi kendine birleştiren sorgularda da aynı davranış gözlemlenebilir.

Bir sorgu varyantının ShowPlan XML'si, seçilen her iki öncülün de ilgili bilgilerinin PLAN PER VALUE PSP ile ilgili ipucu eklendiği aşağıdaki örneğe benzer olacaktır.

<Batch>
  <Statements>
    <StmtSimple StatementText="SELECT  b.PropertyId, &#xD;&#xA;       AgentId, &#xD;&#xA;       MLSLinkId, &#xD;&#xA;       ListingPrice, &#xD;&#xA;       ZipCode, &#xD;&#xA;       Bedrooms, &#xD;&#xA;       Bathrooms &#xD;&#xA;FROM dbo.AgentProperty a join  PropertyDetails b on a.PropertyId = b.PropertyId&#xD;&#xA;WHERE AgentId = @AgentId and  Property_id=@Property_id&#xD;&#xA;UNION&#xD;&#xA;          SELECT  c.PropertyId, &#xD;&#xA;       AgentId, &#xD;&#xA;       MLSLinkId, &#xD;&#xA;       ListingPrice, &#xD;&#xA;       ZipCode, &#xD;&#xA;       Bedrooms, &#xD;&#xA;       Bathrooms &#xD;&#xA;FROM dbo.AgentProperty c join  PropertyDetails d on c.PropertyId = d.PropertyId&#xD;&#xA;WHERE AgentId = @AgentId and  Property_id=@Property_id option (PLAN PER VALUE(ObjectID = 981578535, QueryVariantID = 9, predicate_range([PropertyMLS].[dbo].[AgentProperty].[AgentId] = @AgentId, 100.0, 1000000.0),predicate_range([PropertyMLS].[dbo].[AgentProperty].[AgentId] = @AgentId, 100.0, 1000000.0)))" StatementId="1" StatementCompId="2" StatementType="SELECT" StatementSqlHandle="0x090051FBCD918F8DFD60D324887356B422D90000000000000000000000000000000000000000000000000000" DatabaseContextSettingsId="2" ParentObjectId="0" StatementParameterizationType="1" RetrievedFromCache="false" StatementSubTreeCost="29.2419" StatementEstRows="211837" SecurityPolicyApplied="false" StatementOptmLevel="FULL" QueryHash="0x6D2A4E407085C01E" QueryPlanHash="0x72101C0A0DD861AB" CardinalityEstimationModelVersion="160" BatchModeOnRowStoreUsed="true">
      <StatementSetOptions QUOTED_IDENTIFIER="true" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="true" ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" NUMERIC_ROUNDABORT="false" />
      <Dispatcher>
        <ParameterSensitivePredicate LowBoundary="100" HighBoundary="1e+06">
          <StatisticsInfo LastUpdate="2022-08-11T20:42:35.02" ModificationCount="0" SamplingPercent="100" Statistics="[NCI_AgentProperty_AgentId]" Table="[AgentProperty]" Schema="[dbo]" Database="[PropertyMLS]" />
          <Predicate>
            <ScalarOperator ScalarString="[PropertyMLS].[dbo].[AgentProperty].[AgentId] as [a].[AgentId]=[@AgentId]">
              <Compare CompareOp="EQ">
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Database="[PropertyMLS]" Schema="[dbo]" Table="[AgentProperty]" Alias="[a]" Column="AgentId" />
                  </Identifier>
                </ScalarOperator>
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Column="@AgentId" />
                  </Identifier>
                </ScalarOperator>
              </Compare>
            </ScalarOperator>
          </Predicate>
        </ParameterSensitivePredicate>
        <ParameterSensitivePredicate LowBoundary="100" HighBoundary="1e+06">
          <StatisticsInfo LastUpdate="2022-08-11T20:42:35.02" ModificationCount="0" SamplingPercent="100" Statistics="[NCI_AgentProperty_AgentId]" Table="[AgentProperty]" Schema="[dbo]" Database="[PropertyMLS]" />
          <Predicate>
            <ScalarOperator ScalarString="[PropertyMLS].[dbo].[AgentProperty].[AgentId] as [c].[AgentId]=[@AgentId]">
              <Compare CompareOp="EQ">
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Database="[PropertyMLS]" Schema="[dbo]" Table="[AgentProperty]" Alias="[c]" Column="AgentId" />
                  </Identifier>
                </ScalarOperator>
                <ScalarOperator>
                  <Identifier>
                    <ColumnReference Column="@AgentId" />
                  </Identifier>
                </ScalarOperator>
              </Compare>
            </ScalarOperator>
          </Predicate>
        </ParameterSensitivePredicate>
      </Dispatcher>
      <QueryPlan CachedPlanSize="160" CompileTime="17" CompileCPU="17" CompileMemory="1856" QueryVariantID="9">

PSP iyileştirme özelliği tarafından kullanılan geçerli dengesizlik eşiklerini aşağıdaki yöntemlerden biriyle veya daha fazlasıyla etkileyebilirsiniz:
- Kardinalite tahmincisi (CE) izleme bayrakları, örneğin izleme bayrağı 9481 (genel, oturum veya sorgu düzeyi) gibi
- Kullanımdaki CE modelini düşürmeye veya CE modelinin birden çok koşulun bağımsızlığına ilişkin varsayımlarını etkilemeye çalışan veritabanı kapsamlı yapılandırma seçenekleri. Bu, özellikle çok sütunlu istatistiklerin mevcut olmadığı durumlarda kullanışlıdır ve bu durum PSP iyileştirmesinin bu önkoşulların adaylığını değerlendirme becerisini etkiler.
- Daha fazla bilgi için SQL Server 2014 Kardinalite Tahmin Aracı teknik incelemesiyle sorgu planlarınızı iyileştirme bölümünün Birden Çok Koşul için Artan Bağıntı Varsayımı bölümüne bakın. Daha yeni CE modeli, predikatların birleşim ve ayrışımında bazı bağıntılar olduğunu ve daha az bağımsız olduklarını varsaymaya çalışır. Eski CE modelinin kullanılması, çok sütunlu birleştirme senaryosunda koşul seçiciliğini nasıl hesaplayabileceğinizi etkileyebilir. Bu eylem yalnızca belirli senaryolarda dikkate alınmalıdır ve çoğu iş yükü için eski CE modelinin kullanılması önerilmez.
PSP iyileştirmesi şu anda her sorgu değişkenini yeni hazırlanmış bir deyim olarak derleyip yürütür. Bu, dağıtıcı planının bir modüle (saklı yordam, tetikleyici, işlev, görünüm vb.) dayalı olması durumunda sorgu değişkenlerinin herhangi bir üst modülle ilişkisini object_id nedenlerinden biridir. Hazırlanmış bir deyim olarak, object_id içindeki bir nesneye sys.objects doğrudan eşlenebilen bir şey değildir, ancak temelde toplu iş metninin iç karması temelinde hesaplanan bir değerdir. Daha fazla bilgi için DMV belgelerinin sys.dm_exec_plan_attributes bölümüne bakın.

Sorgu değişken planları plan önbelleği nesne deposuna (CACHESTORE_OBJCP) yerleştirilirken dağıtıcı planları SQL Planları önbellek deposuna (CACHESTORE_SQLCP ) yerleştirilir. Ancak PSP özelliği, üst sorgu bir modülün parçasıysa ve dinamik veya geçici T-SQL değilse, PSP'nin ShowPlan XML'sine eklediği PLAN PER VALUE ipucunun parçası olan ObjectID özniteliğinde, bir sorgu varyantının ebeveynini object_id depolar. Önbelleğe alınmış yordamlar, işlevler ve tetikleyiciler için toplam performans istatistikleri ilgili amaçları doğrultusunda kullanılmaya devam edilebilir. DMV'ye sys.dm_exec_query_stats benzer görünümlerde bulunanlar gibi daha ayrıntılı yürütmeyle ilgili istatistikler yine de sorgu varyantları için veriler içerir, ancak daha ayrıntılı çalışma zamanı istatistiklerinin gerekli olduğu sorgu değişkenlerinin her biri için ShowPlan XML'sinin ek işlenmesine gerek kalmadan, sorgu varyantları ve tablo içindeki object_id nesneler arasındaki sys.objects ilişki şu anda aynı değildir. Sorgu Deposu etkinse, sorgu değişkenleri için çalışma zamanı ve bekleme istatistikleri bilgileri, ek ShowPlan XML ayrıştırma teknikleri olmadan Sorgu Deposu'ndan alınabilir.
PSP sorgu türleri yeni bir hazırlanmış ifade olarak yürütüldüğünden, object_id ShowPlan XML'sini parçalamadan ve metin deseni eşleştirme teknikleri (yani, ek XQuery işleme) uygulamadan çeşitli plan önbelleğiyle ilgili sys.dm_exec_* DMV'lerinde otomatik olarak görünmez. Şu anda yalnızca PSP optimizasyon dağıtımcı planları uygun üst nesne kimliğini yayınlar. Sorgu Deposu, plan önbelleği hiyerarşisinin sağladığından daha ilişkisel bir modeli mümkün kıldığından, object_id Sorgu Deposu içinde görünür hale gelir. Daha fazla bilgi için bkz. Sorgu Deposu sistem kataloğu görünümü sys.query_store_query_variant.

Considerations

PSP iyileştirmesini etkinleştirmek için, sorguyu yürütürken bağlandığınız veritabanı için veritabanı uyumluluk düzeyi 160'ı etkinleştirin.
PSP iyileştirme özelliğiyle ilgili ek içgörüler için Sorgu Deposu'yu açarak Sorgu Deposu tümleştirmesinin etkinleştirilmesini öneririz. Aşağıdaki örnek, adlı MyNewDatabaseönceden var olan bir veritabanı için Sorgu Deposu'yu açar:

ALTER DATABASE [MyNewDatabase]
SET QUERY_STORE = ON (
    OPERATION_MODE = READ_WRITE,
    QUERY_CAPTURE_MODE = AUTO
);

Note

SQL Server 2022 'den (16.x) başlayarak, Sorgu Deposu artık yeni oluşturulan tüm veritabanları için varsayılan olarak etkindir.

PSP iyileştirmesini veritabanı düzeyinde devre dışı bırakmak için veritabanı kapsamlı yapılandırmasını kullanın ALTER DATABASE SCOPED CONFIGURATION SET PARAMETER_SENSITIVE_PLAN_OPTIMIZATION = OFF .
PSP iyileştirmesini sorgu düzeyinde devre dışı bırakmak için sorgu ipucunu DISABLE_PARAMETER_SENSITIVE_PLAN kullanın.
Parametre algılama, izleme bayrağı 4136, PARAMETER_SNIFFING veritabanı kapsamlı yapılandırma veya USE HINT('DISABLE_PARAMETER_SNIFFING') sorgu ipucu tarafından devre dışı bırakılırsa, ilişkili iş yükleri ve yürütme bağlamları için PSP iyileştirme devre dışı bırakılır. Daha fazla bilgi için bkz. Sorgu ipuçları ve ALTER DATABASE SCOPED CONFIGURATION.
Plan önbelleğinde depolanan dağıtıcı başına benzersiz plan değişkenlerinin sayısı, önbelleğin şişirılmasını önlemek için sınırlıdır. İç eşik belgelenmemiş. Her SQL toplu işleminin birden çok plan oluşturma olasılığı olduğundan ve her sorgu değişken planının plan önbelleğinde bağımsız bir girişi olduğundan, varsayılan izin verilen plan girdisi sayısına ulaşmak mümkündür. Plan önbelleği çıkarma oranı gözlemlenebilir düzeyde yüksekse veya CACHESTORE_OBJCPCACHESTORE_SQLCP boyutları aşırıysa, iz bayrağı 174'ü uygulamayı düşünmelisiniz.
Sorgu Deposu deposundaki bir sorgu için depolanan benzersiz plan değişkenlerinin sayısı yapılandırma seçeneğiyle max_plans_per_query sınırlıdır. Sorgu değişkenlerinin birden fazla planı olabileceğinden, Sorgu Deposu'nun içindeki sorgu başına toplam 200 plan bulunabilir. Bu sayı, bir üst sorguya ait tüm dağıtıcılar için tüm sorgu değişken planlarını içerir. Query Store yapılandırma seçeneğini artırmayı göz önünde bulundurun.
- Benzersiz plan sayısının varsayılan Sorgu Deposu max_plans_per_query sınırını nasıl aşabileceğini gösteren bir örnek, aşağıdaki davranışa sahip olduğunuz bir senaryo olabilir. İki dağıtıcı planı olan ve her dağıtıcı planının her birinde 20 sorgu değişkeni (toplamda 40 sorgu değişkeni) bulunan 10 Sorgu Kimliğine sahip bir sorgunuz olduğunu varsayalım. Sorgu Kimliği No. 10 için sorgu varyantları ve iki dağıtıcı planı dahil toplam 40 plan bulunmaktadır. Ana sorgunun kendisi (Sorgu Kimliği 10) ayrıca 5 normal (dağıtıcı olmayan) planı olabilir. Bu, 47 plan yapar (sorgu değişkenlerinden 40, 2 dağıtıcı ve PSP ile ilgili olmayan 5 plan). Ayrıca, her sorgu değişkeninin ortalama beş planı varsa, bu senaryoda üst sorgu için Sorgu Deposu'nda 200'den fazla plan olması mümkündür. Bu durum, bu örnek üst sorgunun başvurabileceği veri kümelerindeki ağır veri dengesizliklerine de bağlıdır.
Belirli bir dağıtıcıya her sorgu değişken eşlemesi için:
- query_plan_hash benzersizdir. Bu sütun sys.dm_exec_query_stats, aynı zamanda diğer dinamik yönetim görünümlerinde ve katalog tablolarında kullanılabilir.
- plan_handle benzersizdir. Bu sütun, , sys.dm_exec_query_stats, sys.dm_exec_sql_textve diğer Dinamik Yönetim Görünümlerinde ve İşlevlerinde ve katalog tablolarında kullanılabilirsys.dm_exec_cached_plans.
- query_hash, aynı dağıtıcıyla eşlenmiş diğer çeşitlemelerde yaygındır, bu nedenle yalnızca giriş parametresi değerlerine göre farklılık gösteren sorgular için toplam kaynak kullanımını belirlemek mümkündür. Bu sütun sys.dm_exec_query_stats, sys.query_store_query ve diğer Dinamik Yönetim Görünümleri ile katalog tablolarında kullanılabilir.
- sql_handle, derleme sırasında sorgu metnine eklenen özel PSP iyileştirme tanımlayıcıları nedeniyle benzersizdir. Bu sütun, , sys.dm_exec_query_stats, sys.dm_exec_sql_textve diğer Dinamik Yönetim Görünümlerinde ve İşlevlerinde ve katalog tablolarında kullanılabilirsys.dm_exec_cached_plans. Sorgu Deposu'nda, katalog tablosundaki last_compile_batch_sql_handle sütunu olarak sys.query_store_query aynı tanıtıcı bilgileri mevcuttur.
- query_id, Sorgu Deposu'nda benzersizdir. Bu sütun sys.query_store_query ve diğer Sorgu Deposu katalog tablolarında kullanılabilir.

Sorgu Deposu'nda zorlamayı planlama

Dağıtıcı veya varyant planlarda çalışmak için aynı sp_query_store_force_plan ve sp_query_store_unforce_plan saklı yordamları kullanır.

Bir değişken zorlanırsa, üst dağıtıcı zorlanmaz. Bir dağıtıcı zorunlu olarak kullanılırsa, sadece o dağıtıcının varyantları kullanım için uygun kabul edilir.

Diğer dağıtıcılardan daha önce zorlanan varyantlar devre dışı kalır, ancak dağıtıcıları yeniden zorlanana kadar zorunlu durumu korur
Aynı dağıtıcıda daha önce zorlanan ve devre dışı kalan çeşitlemeler yeniden zorlanır

Sorgu Deposu'ndaki sorgu ipucu davranışı

Query Store ipucu bir sorgu varyantına (alt sorgu) eklendiğinde, ipucu PSP olmayan bir sorguya aynı şekilde uygulanır. Query Store'daki üst sorguya da bir ipucu uygulanmışsa, sorgu varyant ipuçları daha yüksek bir önceliğe sahiptir.
Üst sorguya bir Sorgu Deposu ipucu eklendiğinde ve alt sorgunun (sorgu değişkeni) mevcut bir Sorgu Deposu ipucu olmadığında, alt sorgu (sorgu değişkeni) ipucunu üst sorgudan devralır.
Sorgu Deposu'ndaki bir sorgu ipucu üst sorgudan kaldırılırsa, alt sorgulardan (sorgu değişkenleri) da ipucu kaldırılır.
Üst sorguya bir RECOMPILE ipucu eklenirse, mevcut sorgu varyant planları plan önbelleğinden kaldırıldıktan sonra sistem PSP dışı planlar üretir, çünkü PSP özelliği, RECOMPILE ipucuna sahip sorgularda çalışmaz.
Sorgu Deposu ipucu sonuçları Genişletilmiş Olaylar query_store_hints_application_success ve query_store_hints_application_failed olaylar kullanılarak gözlemlenebilir. sys.query_store_query_hints tablosu için, uygulanmış olan sorgu ipucuyla ilgili bilgiler içerir. İpucu yalnızca bir üst sorguya uygulanmışsa, alt sorgular üst sorgunun ipucunu devralsa da, sistem kataloğu üst sorgu için ipucu bilgilerini içerir, ancak alt sorgular için değil.

Sorgu ipuçları ve plan zorlama davranışı içeren PSP aşağıdaki tabloda özetlenebilir:

Sorgu değişken ipucu veya planı	Ana öğede kullanıcı tarafından uygulanmış ipucu var	Üst öğede geri bildirim uygulanmış ipucu var	Üst öğe el ile plan yapmaya zorlandı	Ana birimde APC ¹ zorunlu plan var
Kullanıcı aracılığıyla ipucu	Sorgu varyant önerisi	Sorgu varyant önerisi	Sorgu varyant önerisi	N/A
Geri bildirim yoluyla ipucu	Sorgu varyant önerisi	Sorgu varyant önerisi	Sorgu varyant önerisi	N/A
Plan kullanıcı tarafından zorunlu kılındı	Sorgu değişkeni zorunlu plan	Sorgu değişkeni zorunlu plan	Sorgu değişkeni zorunlu plan	Sorgu değişkeni zorunlu plan
APC tarafından dayatılan plan	Sorgu değişkeni zorunlu plan	Sorgu değişkeni zorunlu plan	Sorgu değişkeni zorunlu plan	Sorgu değişkeni zorunlu plan
İpucu veya zorlamalı plan yok	Ana kullanıcının ipucu	İpucu yok	Eylem yok	Eylem yok

¹ Otomatik ayarlama özelliğinin otomatik plan düzeltme bileşeni

Genişletilmiş Olaylar

parameter_sensitive_plan_optimization_skipped_reason: Parametre duyarlı plan özelliğinin atlandığı durumlarda meydana gelir. PSP iyileştirmesinin atlanma nedenini izlemek için bu olayı kullanın.

Aşağıdaki sorgu, PSP'nin atlanma nedenlerinin tümünü gösterir:
```
SELECT map_value
FROM sys.dm_xe_map_values
WHERE [name] = 'psp_skipped_reason_enum'
ORDER BY map_key;
```
parameter_sensitive_plan_optimization: Bir sorgu PSP iyileştirme özelliğini kullandığında gerçekleşir. Yalnızca hata ayıklama kanalı. bazı ilgi alanları şunlar olabilir:
- is_query_variant: Bunun bir dağıtıcı planı mı (üst) yoksa sorgu değişken planı mı (alt) olduğunu açıklar
- predicate_count: PSP tarafından seçilen koşul sayısı
- query_variant_id: Sorgu değişken kimliğini görüntüler. 0 değeri, nesnenin bir dağıtıcı planı (ebeveyn) olduğu anlamına gelir.
query_with_parameter_sensitivity: Tetiklendiğinde bu olay, özelliğin ilgi çekici bulduğu önerme sayısını, ilgi çekici önermelerle ilgili olarak json biçiminde daha fazla ayrıntı ve önerme veya önermeler için PSPO'nun desteklenip desteklenmediğini gösterir.
Genişletilmiş olaydan query_with_parameter_sensitivity örnek çıktı

Field	Value
interesting_predicate_count	3
interesting_predicate_details	{"Predicates":[{"ColumnId":7,"TableId":1221579390,"Skewness":475038.75},{"ColumnId":7,"TableId":1221579390,"Skewness":475038.75},{"ColumnId":7,"TableId":1221579390,"Skewness":475038.75}]}
psp_optimization_supported	True
query_type	195

SQL Server Denetim davranışı

PSP iyileştirmesi, dağıtıcı plan ifadesi ve dağıtıcıyla ilişkili tüm sorgu varyantları için denetim verilerini sağlar. SQL Server Denetimi'nin additional_information içindeki sütun, sorgu değişkenleri için uygun T-SQL yığın bilgilerini de sağlar. MyNewDatabase veritabanını örnek olarak ele alarak, bu veritabanında T2 adlı bir tablo ve usp_test adlı bir saklı yordam varsa, usp_test saklı yordamının yürütülmesinden sonra, denetim günlüğü aşağıdaki girdileri içerebilir:

action_id	object_name	statement	additional_information
AUSC			`<action_info xmlns="http://schemas.microsoft.com/sqlserver/2008/sqlaudit_data"><session><![CDATA[Audit_Testing_Psp$A]]></session><action>event enabled</action><startup_type>manual</startup_type><object><![CDATA[audit_event]]></object></action_info>`
EX	usp_test	exec usp_test 300
SL	T2	dbo.t2'den * seçin, burada ID=@id	`<tsql_stack><frame nest_level = '1' database_name = 'MyNewDatabase' schema_name = 'dbo' object_name = 'usp_test'/></tsql_stack>`
SL	T2	dbo.t2 dosyasından * seçin; burada ID=@id seçeneği (PLAN PER VALUE(ObjectID = 933578364, QueryVariantID = 1, predicate_range([MyNewDatabase].[ dbo]. [T2]. [ID] = @id, 100.0, 100000.0)))	`tsql_stack><frame nest_level = '1' database_name = 'MyNewDatabase' schema_name = 'dbo' object_name = 'usp_test'/></tsql_stack>`
EX	usp_test	exec usp_test 60000
SL	T2	dbo.t2'den * seçin, burada ID=@id	`<tsql_stack><frame nest_level = '1' database_name = 'MyNewDatabase' schema_name = 'dbo' object_name = 'usp_test'/></tsql_stack>`
SL	T2	select * from dbo.t2 where ID=@id option (PLAN PER VALUE(ObjectID = 933578364, QueryVariantID = 3, predicate_range([TestDB_FOR_PSP].[ dbo]. [T2]. [ID] = @id, 100.0, 100000.0)))	`<tsql_stack><frame nest_level = '1' database_name = 'MyNewDatabase' schema_name = 'dbo' object_name = 'usp_test'/></tsql_stack>`

Bilinen sorunlar

Issue	Bulunan tarih	Status	Çözümlenme tarihi
Erişim İhlali özel durumu, SQL Server 2022'deki (16.x) Sorgu Deposu'nda belirli koşullar altında oluşur. PSP optimizasyonu Sorgu Deposu entegrasyonu etkinleştirildiğinde erişim ihlali istisnalarıyla karşılaşabilirsiniz. Daha fazla bilgi için Parametre Duyarlı Plan İyileştirme, Neden? bölümüne bakınız.	Mart 2023	Resolved	Ağustos 2023 (CU 7)
SQL Server 2025'te (17.x) belirli koşullar altında okunabilir ikincil çoğaltmalarda erişim ihlali istisnası oluşabilir. PsP iyileştirmesi okunabilir ikinciller için Sorgu Deposu özelliğini kullanacak şekilde yapılandırılmış okunabilir bir ikincil veritabanında etkinleştirildiğinde erişim ihlali eylemleriyle karşılaşabilirsiniz.	Eylül 2025	Geçici çözümü var

Geçici çözümü var

Belirli koşullar altında okunabilir ikincil kopyalar üzerinde erişim ihlali istisnası oluşabilir.

PsP sorgu değişkeni üst dağıtıcı deyiminin kalıcı durumunu belirleyemediğinde aşağıdaki koşulları karşılayan sorgular erişim ihlaliyle karşılaşabilir:

İkincil kopyada yürütüldü
Parametre koklamaya duyarlı
Parametreye duyarlı plan (PSP) optimizasyonu için uygun

Geçici çözüm: Okunabilir ikinciller için Sorgu Deposu özelliğini kullanmak üzere eklenen her veritabanı için ikincil cihazlarda PSP'yi devre dışı bırakın. Belirli bir veritabanı bağlamından aşağıdaki Transact-SQL deyimini çalıştırın:

ALTER DATABASE SCOPED CONFIGURATION FOR SECONDARY
    SET PARAMETER_SENSITIVE_PLAN_OPTIMIZATION = OFF;

Resolved

Belirli koşullar altında SQL Server 2022'deki Sorgu Deposu'nda erişim ihlali özel durumu oluşuyor

Note

SQL Server 2022 (16.x) Toplu Güncelleştirme 7 , erişim ihlaline neden olabilecek bir yarış durumu için çeşitli düzeltmeler yayımladı.

Bu sorun, çalıştırılan bir sorgunun çalışma zamanı istatistikleri Sorgu Deposu'nun bellek içi gösteriminden (hafıza görevlisinde MEMORYCLERK_QUERYDISKSTORE_HASHMAP bulunan) Sorgu Deposu'nun disk üzerindeki sürümüne aktarılırken oluşabilecek bir yarış durumu nedeniyle meydana geldi. Çalışma Zamanı İstatistikleri olarak gösterilen çalışma zamanı istatistikleri, deyiminin seçeneğiyle DATA_FLUSH_INTERVAL_SECONDSSET QUERY_STORE tanımlanan bir süre boyunca bellekte tutulur (varsayılan değer 15 dakikadır). Management Studio Sorgu Deposu iletişim kutusunu kullanarak dahili olarak saniyelere dönüştürülen Veri Temizleme Aralığı (Dakika) değerini girebilirsiniz. Sistem bellek sıkışıklığı yaşanıyorsa, çalışma istatistikleri DATA_FLUSH_INTERVAL_SECONDS seçeneğiyle tanımlanandan daha önce diske boşaltılabilir. Sorgu Deposundaki sorgu planı temizliğine ilişkin (STALE_QUERY_THRESHOLD_DAYS ve/veya MAX_STORAGE_SIZE_MB Sorgu Deposu seçenekleri) ek Sorgu Deposu arka plan iş parçacıkları olduğunda, Sorgu Deposu'ndan gelen sorgularla ilgili bir senaryo ortaya çıkar. Bu durumda, bir sorgu variantı ve/veya bununla ilişkili bir dağıtıcı deyimi erken dönemde referans dışı kalabilir. Bu, Sorgu Deposu'na sorgu değişkenlerinin ekleme veya silme işlemleri sırasında erişim ihlaline neden olabilir.

Sorgu Deposu işlemleri hakkında daha fazla bilgi için Sorgu Deposu Verileri Nasıl Toplar makalesinin Açıklamalar bölümüne bakın.

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2025-11-18

Aracılığıyla paylaş

Parametreye Duyarlı Plan Optimizasyonu

Parametreleştirmeyi anlama

PSP iyileştirme uygulaması

Terminology

Dispatcher ifadesi

Dağıtıcı planı

Sorgu değişkeni

Predikat kardinalite aralığı

Remarks

Considerations

Sorgu Deposu'nda zorlamayı planlama

Sorgu Deposu'ndaki sorgu ipucu davranışı

Genişletilmiş Olaylar

SQL Server Denetim davranışı

Bilinen sorunlar

Geçici çözümü var

Belirli koşullar altında okunabilir ikincil kopyalar üzerinde erişim ihlali istisnası oluşabilir.

Resolved

Belirli koşullar altında SQL Server 2022'deki Sorgu Deposu'nda erişim ihlali özel durumu oluşuyor

İlgili içerik

Geri Bildirim

Ek kaynaklar