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

Ana sorgu

PSP optimizasyonunun bir gönderici planı ve sorgu varyantları oluşturduğu özgün parametreli sorgu. Sorgu varyantları, ana sorgunun alt sorgularıdır. Query Store, aynı ebeveyn sorgu için zamanla birden fazla dispatcher planını tutabilir.

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ı

dispatcher ifadesini içeren bir plan, orijinal parametreli sorgu için önbelleklenir; bu sorgu ana sorgu olarak da bilinir. dispatcher planı, esasen özelliğin seçtiği yüklemlerin bir koleksiyonudur ve birkaç ekstra detay içerir. Her seçilen predikat için, dispetçer planı yüksek ve düşük sınır değerlerini içerir. Bu değerler, parametre değerlerini farklı kovalara veya aralıklara böler. 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 (DML) ifadeleri desteği.
- tempdb için genişletilmiş destek.
- Aynı tablodan birden fazla uygun predikat seçme desteği, her sütun başına en fazla bir predikat seçimi.
- SQL Server 2025 (17.x) ve veritabanı uyumluluğu query_with_parameter_sensitivity 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.
Veritabanı uyumluluk seviyesi 160'ta, aynı tablo referansının parçası olan birden fazla uygun yüklem olduğunda, PSP optimizasyonu, temel istatistik histogramına göre en fazla veri çarpıklığına sahip yüklemi seçer. Örneğin, SELECT * FROM table1 WHERE column1 = @predicate1 AND column2 = @predicate2 ile sadece en çarpık yüklem seçilir çünkü her iki yüklem de aynı tabloya atıfta bulunur. Ancak, sorgu tabloya birden fazla kez referans verirse, örneğin ayrı dallarda UNION veya self join'deki takma adlar aracılığıyla, PSP optimizasyonu birden fazla tablo referansından predikatlar seçebilir.
SQL Server 2025 (17.x) ve veritabanı uyumluluk seviyesi 170 ile başlayarak, PSP optimizasyonu aynı tablodan birden fazla uygun yüklem seçebilir. Her sütun için yalnızca bir yüklem seçilir ve sorgu için seçilen toplam yüklem sayısı üç ile sınırlı kalır. Örneğin, her iki SELECT * FROM table1 WHERE column1 = @predicate1 AND column2 = @predicate2 yüklem de PSP optimizasyonu kriterlerini karşılıyorsa seçilebilir.

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 optimizasyonu, her sorgu varyantını ayrı hazırlanmış bir deyim olarak derler ve çalıştırır. Sorgu varyant planları önbelleğe alınabilir ve yeniden kullanılabilir, bu yüzden her yürütme için yeni bir derleme gerekmez. Sorgu varyantları ayrı hazırlanmış ifadeler olduğundan, plan önbellek object_id değerleri, ebeveyn sorgu bir modülün parçasıysa (yani depolanmış prosedür, tetikleyici, fonksiyon vb.) ana modülü tanımlamaz. Hazırlanmış bir deyim için plan önbelleği object_id, sys.objects içindeki bir nesnenin kimliği yerine, esasen toplu iş metninin iç karmasına dayanan hesaplanmış bir değerdir. Daha fazla bilgi için DMV belgelerinin sys.dm_exec_plan_attributes bölümüne bakın.

Sorgu varyant planları SQL Planları önbellek deposuna yerleştirilir (CACHESTORE_SQLCP). dispatcher planı, orijinal parti veya modülün önbelleklenmiş planının bir parçası olarak kalır. Eğer ana sorgu, depolanmış bir prosedürün veya derlenmiş planı Nesne Planları önbellek deposunda (CACHESTORE_OBJCP) saklanan başka bir modülün parçasıysa, dispatcher planı CACHESTORE_OBJCP içinde saklanır. Eğer ana sorgu parametreli dinamik SQL'in veya uygun bir ad hoc toplu işin parçasıysa, dağıtıcı planı CACHESTORE_SQLCP içinde depolanır.

PSP özelliği, bir sorgu varyantının ana modülünün ObjectID özelliğini, ShowPlan XML'deki PLAN PER VALUE ipucunun bir parçası olan object_id özniteliği içinde saklar. Eğer ana sorgu dinamik veya ad hoc T-SQL ise, bu öznitelik 0 olur. Önbelleğe alınmış yordamlar, işlevler ve tetikleyiciler için toplam performans istatistikleri ilgili amaçları doğrultusunda kullanılmaya devam edilebilir. sys.dm_exec_query_stats DMV'de bulunanlar gibi daha ayrıntılı yürütmeyle ilgili istatistikler hâlâ sorgu varyantları için veri içerir. Ancak, bu istatistikleri ana modüle bağlamak, ShowPlan XML'in ek işlenmesini gerektirir, çünkü sorgu varyantının plan önbelleği object_id ana modülü doğrudan tanımlamaz. Sorgu varyantları için çalışma zamanı ve bekleme istatistikleri, Query Store etkinse, ek ShowPlan XML ayrıştırması olmadan Query Store'dan elde edilebilir.
Ana modülün nesne kimliği, plan önbellekle ilgili object_id DMV'lerde sorgu varyantı sys.dm_exec_* olarak doğrudan açığa çıkmaz. Dispatcher'ı içeren önbelleklenmiş modül planı, modülün nesne kimliğini korur. Sorgu varyantları için, ana modülün nesne kimliği, ShowPlan XML'i işleyerek ObjectID ipucundaki PLAN PER VALUE özniteliğinden alınabilir. Query Store, bu ilişkileri tanımlamak için ilişkisel bir model sunar. sys.query_store_query_variant katalog görünümü, orijinal parametreli sorguyu parent_query_id ile, dispetçer planını dispatcher_plan_id ile ve alt sorguyu query_variant_query_id ile tanımlar.

Considerations

PSP optimizasyonunu etkinleştirmek için, sorgu yürütürken bağlı olduğunuz veritabanı için veritabanı uyumluluk seviyesi 160 veya daha üzerini kullanın. SQL Server 2025 (17.x)'de getirilen PSP optimizasyon geliştirmeleri, veritabanı uyumluluk seviyesi 170 veya daha üzerini gerektirir.
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 sorgu varyant planını zorunlu kılıyorsanız, ilgili dispatcher planını zorlamazsınız. 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	dbo.t2'den * seçin burada ID=@id seçeneği (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 (SQL Server 2022 CU 7)
SQL Server 2025'te (17.x) belirli koşullar altında okunabilir ikincil çoğaltmalarda erişim ihlali istisnası oluşabilir. PSP optimizasyonu, okunabilir ikincil çoğaltmalar için Sorgu Deposu özelliğini kullanacak şekilde yapılandırılmış bir okunabilir ikincil veritabanında etkinleştirildiğinde erişim ihlali özel durumlarıyla karşılaşabilirsiniz.	Eylül 2025	Resolved	Ocak 2026 (SQL Server 2025 CU 1)

Resolved

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

(Ocak 2026'da çözüldü)

Parametreye duyarlı plan (PSP) sorgu değişkeni kendi üst dağıtıcı deyiminin kalıcı durumunu belirleyemediğinde, aşağıdaki koşulları karşılayan sorgular bir erişim ihlaliyle karşılaşabilir:

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

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

(Mart 2023'te çözüldü)

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?

Son güncelleştirme: 2026-10-28

Parametreye Duyarlı Plan Optimizasyonu

Parametreleştirmeyi anlama

PSP iyileştirme uygulaması

Terminology

Ana sorgu

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

Resolved

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

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