Metodtips för övervakning av arbetsbelastningar med Query Store

Artikel
03/05/2025

gäller för: SQL Server 2016 (13.x) och senare versioner Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics (endast dedikerad SQL-pool)SQL-databas i Microsoft Fabric

Den här artikeln beskriver metodtipsen för att använda SQL Server Query Store med din arbetsbelastning.

Mer information om hur du konfigurerar och administrerar med Query Store finns i Övervakningsprestanda med hjälp av Query Store-.
Information om hur du identifierar användbar information och finjusterar prestanda med Query Store finns i Tuning performance by using the Query Store.
Information om hur du kör Query Store i Azure SQL Database finns i Använda Query Store i Azure SQL Database.
I Azure Synapse Analytics är Query Store inte aktiverat som standard för dedikerade SQL-pooler, utan kan aktiveras. Ytterligare konfigurationsalternativ för Query Store stöds inte. Mer information finns i Historisk frågelagring och analys i Azure Synapse Analytics.

Använda den senaste SQL Server Management Studio

SQL Server Management Studio har en uppsättning användargränssnitt som är utformade för att konfigurera Query Store och för användning av insamlade data om din arbetsbelastning. Ladda ned den senaste versionen av SQL Server Management Studio.

En snabb beskrivning av hur du använder Query Store i felsökningsscenarier finns i Query Store Azure blogs.

Använda Query Performance Insight i Azure SQL Database

Om du kör Query Store i Azure SQL Database kan du använda Query Performance Insight för att analysera resursförbrukningen över tid. Du kan använda Management Studio och Azure Data Studio för att få detaljerad resursförbrukning för alla dina frågor, till exempel CPU, minne och I/O, men Query Performance Insight ger dig ett snabbt och effektivt sätt att fastställa deras effekt på den totala DTU-förbrukningen för databasen. Mer information finns i Azure SQL Database Query Performance Insight.

Om du vill övervaka prestanda i Fabric SQL Databaseanvänder du instrumentpanelen Prestanda.

Använda Query Store med elastiska pooldatabaser

Du kan använda Query Store i alla databaser utan problem, även i tätt packade elastiska Azure SQL Database-pooler. Alla tidigare problem som rör överdriven resursanvändning som kan ha uppstått när Query Store aktiverades för det stora antalet databaser i de elastiska poolerna har lösts.

Börja med felsökning av frågeprestanda

Felsökningsarbetsflödet med Query Store är enkelt, vilket visas i följande diagram:

diagram över felsökning av Query Store: Aktivera Query Store, Låt Query Store samla in data, Hitta och åtgärda problematiska frågor.

Aktivera Query Store med hjälp av Management Studio enligt beskrivningen i föregående avsnitt eller kör följande Transact-SQL-instruktion:

ALTER DATABASE [DatabaseOne] SET QUERY_STORE = ON;

Det tar lite tid innan Query Store samlar in datamängden som representerar din arbetsbelastning korrekt. Vanligtvis räcker en dag även för mycket komplexa arbetsbelastningar. Du kan dock börja utforska data och identifiera frågor som behöver din uppmärksamhet direkt efter att du har aktiverat funktionen. Gå till undermappen Query Store under databasnoden i Object Explorer of Management Studio för att öppna felsökningsvyer för specifika scenarier.

Management Studio Query Store-vyer fungerar med en uppsättning utförandemått, som var och en uttrycks som någon av följande statistikfunktioner:

SQL Server-version	Körningsmått	Statistikfunktion
SQL Server 2016 (13.x)	CPU-tid, varaktighet, körningsantal, logiska läsningar, logiska skrivningar, minnesförbrukning, fysiska läsningar, CLR-tid, grad av parallellitet (DOP) och antal rader	Medelvärde, Maximum, Minimum, Standardavvikelse, Total
SQL Server 2017 (14.x)	CPU-tid, varaktighet, antal körningar, logiska läsningar, logiska skrivningar, minnesförbrukning, fysiska läsningar, CLR-tid, grad av parallellitet, antal rader, loggminne, TempDB-minne och väntetider	Medelvärde, Maximumvärde, Minimumvärde, Standardavvikelse, Totalt

Följande bild visar hur du hittar Query Store-vyer:

Skärmbild från SSMS som visar platsen för Query Store-vyerna.

I följande tabell förklaras när du ska använda var och en av Query Store-vyerna:

SQL Server Management Studio-vy	Scenarie
regresserade sökfrågor	Identifiera frågeställningar för vilka exekveringsmåtten nyligen regresserat (till exempel ändrat till det sämre). Använd den här vyn för att korrelera observerade prestandaproblem i ditt program med de faktiska frågor som behöver åtgärdas eller förbättras.
övergripande resursförbrukning	Analysera den totala resursförbrukningen för databasen för någon av utförandemåtten. Använd den här vyn för att identifiera resursmönster (dagliga och nattliga arbetsbelastningar) och optimera den totala förbrukningen för databasen.
mest resurskrävande frågor	Välj ett körningsmått av intresse och identifiera frågor som hade de mest extrema värdena för ett angivet tidsintervall. Använd den här vyn för att fokusera din uppmärksamhet på de mest relevanta frågorna som har störst effekt på databasens resursförbrukning.
frågeställningar med framtvingade planer	Listar tidigare framtvingade planer med hjälp av Query Store. Använd den här vyn för att snabbt få åtkomst till alla för närvarande framtvingade planer.
frågor med hög variation	Analysera frågor med hög exekveringsvariation i förhållande till någon av de tillgängliga parametrarna, till exempel varaktighet, CPU-tid, I/O och minnesanvändning, under det angivna tidsintervallet. Använd den här vyn för att identifiera frågor med mycket olika prestanda som kan påverka användarupplevelsen i dina program.
Förfrågeväntestatistik	Analysera väntekategorier som är mest aktiva i en databas och vilka frågor som bidrar mest till den valda väntekategorin. Använd den här vyn för att analysera väntestatistik och identifiera frågor som kan påverka användarupplevelsen i dina program. Gäller för: Börjar med SQL Server Management Studio v18.0 och SQL Server 2017 (14.x).
spårade sökfrågor	Spåra utförandet av de viktigaste frågorna i realtid. Vanligtvis använder du den här vyn när du har frågor med framtvingade planer och vill se till att frågeprestandan är stabil.

Tips

En detaljerad beskrivning av hur du använder Management Studio för att identifiera de vanligaste resurskrävande frågorna och åtgärda dem som har regresserats på grund av ändringen av ett planval finns i Query Store Azure Blogs.

När du identifierar en fråga med suboptimal prestanda beror åtgärden på problemets art.

Om frågan kördes med flera exekveringsplaner och den senast använda planen är betydligt sämre än den tidigare planen, kan du använda mekanismen för att tvinga fram planen. SQL Server försöker framtvinga planen i optimeraren. Om tvång av planen misslyckas utlöses en XEvent och optimeraren instrueras att optimera på normalt sätt.

Skärmbild från SSMS för force plan-knappen för Query Store.

Not

Den tidigare bilden kan innehålla olika former för specifika frågeplaner, med följande betydelser för varje möjlig status:

Form	Betydelse
Cirkel	Frågan har slutförts, vilket innebär att en normal körning har avslutats.
Kvadrat	Avbröts, vilket innebär att en klientinitierad avbruten körning.
Triangel	Misslyckades, vilket innebär att ett undantag avbröt körningen.

Formens storlek återspeglar också antalet körningar av frågor inom det angivna tidsintervallet. Storleken ökar med ett högre antal exekveringar.

Du kan dra slutsatsen att frågan saknar ett index för optimalt utförande. Den här informationen visas i frågekörningsplanen. Skapa det saknade indexet och kontrollera frågeprestandan med hjälp av Query Store.

Skärmbild från SSMS för en Query Store-plan med det saknade indexmeddelandet markerat.

Om du kör din arbetsbelastning i SQL Database registrerar du dig för SQL Database Index Advisor för att automatiskt ta emot indexrekommendationer.

I vissa fall kan du välja att framtvinga en omkompilering av statistik om du ser att skillnaden mellan det uppskattade och det faktiska antalet rader i exekveringsplanen är betydande.
Skriv om problematiska frågor, till exempel för att dra nytta av frågeparameterisering eller implementera mer optimal logik.

Tips

I Azure SQL Database bör du överväga Query Store-tips funktion för att tvinga fram frågetips för frågor utan kodändringar. Mer information och exempel finns i Query Store-tips.

Kontrollera att Query Store samlar in frågedata kontinuerligt

Query Store kan tyst ändra åtgärdsläget. Övervaka regelbundet tillståndet för Query Store för att säkerställa att Query Store fungerar och vidta åtgärder för att undvika fel på grund av orsaker som kan förebyggas. Kör följande fråga för att fastställa åtgärdsläget och visa de mest relevanta parametrarna:

USE [QueryStoreDB];
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Skillnaden mellan actual_state_desc och desired_state_desc anger att en ändring av åtgärdsläget skedde automatiskt. Den vanligaste ändringen är att Query Store tyst växlar till skrivskyddat läge. I extremt sällsynta fall kan Query Store hamna i feltillståndet på grund av interna fel.

När tillståndet är skrivskyddat använder du kolumnen readonly_reason för att fastställa rotorsaken. Normalt ser du att Query Store övergick till skrivskyddat läge eftersom storlekskvoten överskreds. I så fall anges readonly_reason till 65536. För andra skäl, se sys.database_query_store_options (Transact-SQL).

Överväg följande steg för att växla Query Store till läs- och skrivläge och aktivera datainsamling:

Öka den maximala lagringsstorleken med hjälp av alternativet MAX_STORAGE_SIZE_MB för ALTER DATABASE.
Rensa Query Store-data med hjälp av följande instruktion:
```
ALTER DATABASE [QueryStoreDB] SET QUERY_STORE CLEAR;
```

Du kan använda något eller båda av dessa steg genom att utföra följande kommando som uttryckligen ändrar åtgärdsläget tillbaka till läs-skriv.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);

Vidta följande steg för att vara proaktiv:

Du kan förhindra tysta ändringar i åtgärdsläget genom att använda metodtips. Se till att frågearkivets storlek alltid ligger under det maximalt tillåtna värdet för att dramatiskt minska risken för att övergå till skrivskyddat läge. Aktivera storleksbaserad princip enligt beskrivningen i avsnittet Configure Query Store så att Query Store automatiskt rensar data när storleken närmar sig gränsen.
För att säkerställa att de senaste data bevaras konfigurerar du tidsbaserad princip för att ta bort inaktuell information regelbundet.
Slutligen, överväg att ställa in frågearkivets upptagningsläge till Auto eftersom det filtrerar bort frågor som vanligtvis är mindre relevanta för din arbetsbelastning.

FELtillstånd

Om du vill återställa Query Store kan du prova att uttryckligen ange läget för läs-och-skriv och kontrollera det faktiska tillståndet igen.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Om problemet kvarstår indikerar det att skadade Query Store-data sparas på disken.

Från och med SQL Server 2017 (14.x) kan du återställa Query Store genom att köra den sys.sp_query_store_consistency_check lagrade proceduren i den berörda databasen. Query Store måste inaktiveras innan du försöker återställa. Här är en exempelfråga som du kan använda eller ändra för att utföra konsekvenskontrollen och återställningen av QDS:

IF EXISTS (SELECT * FROM sys.database_query_store_options WHERE actual_state=3) 
BEGIN
  BEGIN TRY
    ALTER DATABASE [QDS] SET QUERY_STORE = OFF
    Exec [QDS].dbo.sp_query_store_consistency_check
    ALTER DATABASE [QDS] SET QUERY_STORE = ON
    ALTER DATABASE [QDS] SET QUERY_STORE (OPERATION_MODE = READ_WRITE)
  END TRY
 
  BEGIN CATCH 
    SELECT  
      ERROR_NUMBER() AS ErrorNumber  
      ,ERROR_SEVERITY() AS ErrorSeverity  
      ,ERROR_STATE() AS ErrorState  
      ,ERROR_PROCEDURE() AS ErrorProcedure  
      ,ERROR_LINE() AS ErrorLine  
      ,ERROR_MESSAGE() AS ErrorMessage; 
  END CATCH;   
END

För SQL Server 2016 (13.x) måste du rensa data från Query Store på det sätt som visas.

Om återställningen misslyckades kan du prova att rensa Query Store innan du anger läs-skrivläge.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE CLEAR;
GO

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Undvik att använda icke-parametriserade frågor

Det är inte bästa praxis att använda icke-parametriserade frågor när det inte är nödvändigt. Ett exempel är när det gäller ad hoc-analys. Cachelagrade planer kan inte återanvändas, vilket tvingar Query Optimizer att kompilera frågor för varje unik frågetext. Mer information finns i Riktlinjer för användning av tvingad parameterisering.

Query Store kan också snabbt överskrida storlekskvoten på grund av ett potentiellt stort antal olika frågetexter och därmed ett stort antal olika körningsplaner med liknande form. Därför är arbetsbelastningens prestanda inte optimal och Query Store kan växla till skrivskyddat läge eller hela tiden ta bort data för att försöka hålla jämna steg med inkommande frågor.

Överväg följande alternativ:

Parametrisera frågor där det är tillämpligt. Du kan till exempel omsluta frågor i en lagrad procedur eller sp_executesql. För mer information, se Parametrar och återanvändning av körningsplan.
Använd alternativet optimera för ad hoc-arbetsbelastningar om din arbetsbelastning innehåller många ad hoc-batchar för engångsbruk med olika frågeplaner.
- Jämför antalet distinkta query_hash värden med det totala antalet poster i sys.query_store_query. Om förhållandet är nära 1, genererar dina ad hoc-arbetsuppgifter olika frågor.
Använd tvingad parameterisering för databasen eller för en delmängd frågor om antalet olika frågeplaner inte är stort.
- Använd en -planguide för att endast tvinga fram parameterisering för den valda frågespecifikationen.
- Konfigurera tvingad parameterisering genom att använda parameteriseringsdatabasens alternativ och kommando, om det finns få olika frågeplaner i arbetsbelastningen. Ett exempel är när förhållandet mellan antalet distinkta query_hash och det totala antalet poster i sys.query_store_query är mycket mindre än 1.
Ange QUERY_CAPTURE_MODE till AUTO för att automatiskt filtrera bort ad hoc-frågor med liten resursförbrukning.

Tips

När du använder en lösning för Object-Relational-mappning (ORM), till exempel Entity Framework (EF), kanske inte programfrågor som manuella LINQ-frågeträd eller vissa råa SQL-frågor parametriseras, vilket påverkar återanvändningen av planerna och möjligheten att spåra frågor i Query Store. För mer information, se EF-frågelagring och parameterisering och EF Raw SQL-frågor.

Hitta icke-parametriserade frågor i Query Store

Du hittar antalet planer som lagras i Query Store med hjälp av frågan nedan, med hjälp av Query Store DMV:er, i SQL Server, Azure SQL Managed Instance eller Azure SQL Database:

SELECT count(Pl.plan_id) AS plan_count, Qry.query_hash, Txt.query_text_id, Txt.query_sql_text
FROM sys.query_store_plan AS Pl
INNER JOIN sys.query_store_query AS Qry
    ON Pl.query_id = Qry.query_id
INNER JOIN sys.query_store_query_text AS Txt
    ON Qry.query_text_id = Txt.query_text_id
GROUP BY Qry.query_hash, Txt.query_text_id, Txt.query_sql_text
ORDER BY plan_count desc;

I följande exempel skapas en Extended Events-session för att fånga händelsen query_store_db_diagnostics, vilket kan vara användbart för att diagnostisera förbrukningen av resurser i frågor. I SQL Server skapar den här utökade händelsesessionen en händelsefil i SQL Server-loggmappen som standard. I en SQL Server 2019-standardinstallation (15.x) i Windows ska händelsefilen (.xel-filen) till exempel skapas i mappen C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log. För Azure SQL Managed Instance anger du en Azure Blob Storage-plats i stället. Mer information finns i XEvent-event_file för Azure SQL Managed Instance. Händelsen "qds.query_store_db_diagnostics" är inte tillgänglig för Azure SQL Database.

CREATE EVENT SESSION [QueryStore_Troubleshoot] ON SERVER 
ADD EVENT qds.query_store_db_diagnostics(
      ACTION(sqlos.system_thread_id,sqlos.task_address,sqlos.task_time,sqlserver.database_id,sqlserver.database_name))
ADD TARGET package0.event_file(SET filename=N'QueryStore',max_file_size=(100))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF);

Med dessa data kan du hitta antalet planer i Query Store, och även många andra statistiska data. Leta efter kolumnerna plan_count, query_count, max_stmt_hash_map_size_kboch max_size_mb i händelsedata för att förstå mängden minne som används och antalet planer som spåras av Query Store. Om planantalet är högre än normalt kan det tyda på en ökning av icke-parametriserade frågor. Använd nedanstående DMV-fråga i Query Store för att granska parametriserade och icke-parametriserade frågeställningar i Query Store.

För parametriserade frågor:

SELECT qsq.query_id, qsqt.query_sql_text
FROM sys.query_store_query AS qsq 
INNER JOIN sys.query_store_query_text AS qsqt
ON qsq.query_text_id= qsqt.query_text_id 
WHERE qsq.query_parameterization_type<>0 or qsqt.query_sql_text like '%@%';

För icke-parametriserade frågor:

SELECT qsq.query_id, qsqt.query_sql_text
FROM sys.query_store_query AS qsq 
INNER JOIN sys.query_store_query_text AS qsqt
ON qsq.query_text_id= qsqt.query_text_id 
WHERE query_parameterization_type=0;

Undvik ett DROP- och CREATE-mönster för innehållande objekt

Query Store associerar frågeposten med ett innehållande objekt, till exempel lagrad procedur, funktion och utlösare. När du återskapar ett innehållande objekt genereras en ny frågepost för samma frågetext. Detta hindrar dig från att spåra prestandastatistik för den frågan över tid och använda en mekanism för att tvinga fram en plan. Undvik den här situationen genom att använda ALTER <object> för att ändra en innehållande objektdefinition när det är möjligt.

Kontrollera statusen för framtvingade planer regelbundet

Planpåtryckning är en praktisk mekanism för att förbättra prestandan för kritiska sökfrågor och göra dem mer förutsägbara. Precis som med plantips och planguider är det inte en garanti att tvinga en plan kommer att användas i körningar i framtiden. När databasschemat ändras på ett sätt som gör att objekt som refereras till av körningsplanen ändras eller tas bort, börjar plantvingandet vanligtvis misslyckas. I så fall återgår SQL Server till frågekompilering medan den faktiska tvingande felorsaken visas i sys.query_store_plan. Följande fråga returnerar information om framtvingade planer:

USE [QueryStoreDB];
GO

SELECT p.plan_id, p.query_id, q.object_id as containing_object_id,
    force_failure_count, last_force_failure_reason_desc
FROM sys.query_store_plan AS p
JOIN sys.query_store_query AS q on p.query_id = q.query_id
WHERE is_forced_plan = 1;

En fullständig lista över orsaker finns i sys.query_store_plan. Du kan också använda query_store_plan_forcing_failed XEvent för att spåra och felsöka misslyckade planforceringar.

Tips

I Azure SQL Database bör du överväga Query Store-hintar som en funktion för att tvinga fram frågetips på frågor utan kodändringar. Mer information och exempel finns i Query Store-tips.

Undvik att byta namn på databaser för frågor med framtvingade planer

Exekveringsplaner refererar till objekt genom att använda tredelade namn som database.schema.object.

Om du byter namn på en databas misslyckas plan forcing, vilket leder till omkompilering vid alla efterföljande körningar av frågor.

Använda Query Store på verksamhetskritiska servrar

De globala spårningsflaggorna 7745 och 7752 kan användas för att förbättra tillgängligheten för databaser med hjälp av Query Store. För mer information, se Spårningsflaggor.

Spårningsflagga 7745 förhindrar standardbeteendet där Query Store skriver data till disk innan SQL Server kan stängas av. Det innebär att Query Store-data som har samlats in men ännu inte sparats på disken går förlorade, upp till det tidsfönster som definierats med DATA_FLUSH_INTERVAL_SECONDS.
Spårningsflagga 7752 aktiverar asynkron inläsning av Query Store. På så sätt kan en databas bli online och frågor köras innan Query Store har återställts helt. Standardbeteendet är att utföra en synkron belastning på Query Store. Standardbeteendet förhindrar att frågor körs innan Query Store har återställts, men förhindrar även att frågor missas i datainsamlingen.

Not

Från och med SQL Server 2019 (15.x) styrs det här beteendet av motorn och spårningsflagga 7752 har ingen effekt.

Viktig

Om du använder Query Store för just-in-time-arbetsbelastningsinsikter i SQL Server 2016 (13.x) planerar du att installera prestandaskalbarhetsförbättringarna i SQL Server 2016 (13.x) SP2 CU2 (KB 4340759) så snart som möjligt. Utan dessa förbättringar kan spinlock-konkurrens uppstå och serverns prestanda kan bli låg när databasen är under hög arbetsbelastning. I synnerhet kan du se hård konkurrens på QUERY_STORE_ASYNC_PERSIST spinlock eller SPL_QUERY_STORE_STATS_COOKIE_CACHE spinlock. När den här förbättringen har tillämpats orsakar Query Store inte längre spinlockkonflikt.

Viktig

Om du använder Query Store för just-in-time-arbetsbelastningsinsikter i SQL Server (SQL Server 2016 (13.x) via SQL Server 2017 (14.x)) planerar du att installera prestandaskalbarhetsförbättringen i SQL Server 2016 (13.x) SP2 CU15, SQL Server 2017 (14.x) CU23 och SQL Server 2019 (15.x) CU9 så snart som möjligt. När databasen är under tunga ad hoc-arbetsbelastningar kan Query Store använda en stor mängd minne, och utan denna förbättring kan serverprestandan bli långsam. När den här förbättringen har tillämpats inför Query Store interna gränser för mängden minne som de olika komponenterna kan använda och kan automatiskt ändra åtgärdsläget till skrivskyddat tills tillräckligt med minne har returnerats till databasmotorn. Begränsningar för internt minne i Query Store dokumenteras inte eftersom de kan komma att ändras.

Använd Query Store i Azure SQL Databasens aktiva geo-replikering

Query Store på en sekundär aktiv geo-replik för Azure SQL Database kommer att vara en skrivskyddad kopia av aktiviteten från den primära repliken.

Undvik felmatchade nivåer med geo-replikering i Azure SQL Database. En sekundär databas bör ha eller nära samma beräkningsstorlek för den primära databasen och på samma tjänstnivå som den primära databasen. Leta efter HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO väntetyp i sys.dm_db_wait_stats, som anger strypning av transaktionsloggens hastighet på den primära repliken på grund av eftersläpning hos den sekundära repliken.

Mer information om hur du beräknar och konfigurerar storleken på den sekundära Azure SQL-databasen för aktiv geo-replikering finns i Konfigurera sekundär databas.

Håll Query Store justerat efter din arbetsbelastning

Metodtips och rekommendationer för att konfigurera och hantera Query Store har utökats i den här artikeln: Metodtips för att hantera Query Store-.

Dela via

Metodtips för övervakning av arbetsbelastningar med Query Store

Använda den senaste SQL Server Management Studio

Använda Query Performance Insight i Azure SQL Database

Använda Query Store med elastiska pooldatabaser

Börja med felsökning av frågeprestanda

Kontrollera att Query Store samlar in frågedata kontinuerligt

FELtillstånd

Undvik att använda icke-parametriserade frågor

Hitta icke-parametriserade frågor i Query Store

Undvik ett DROP- och CREATE-mönster för innehållande objekt

Kontrollera statusen för framtvingade planer regelbundet

Undvik att byta namn på databaser för frågor med framtvingade planer

Använda Query Store på verksamhetskritiska servrar

Använd Query Store i Azure SQL Databasens aktiva geo-replikering

Håll Query Store justerat efter din arbetsbelastning

Feedback

Ytterligare resurser

Dela via

Metodtips för övervakning av arbetsbelastningar med Query Store

Använda den senaste SQL Server Management Studio

Använda Query Performance Insight i Azure SQL Database

Använda Query Store med elastiska pooldatabaser

Börja med felsökning av frågeprestanda

Kontrollera att Query Store samlar in frågedata kontinuerligt

FELtillstånd

Undvik att använda icke-parametriserade frågor

Hitta icke-parametriserade frågor i Query Store

Undvik ett DROP- och CREATE-mönster för innehållande objekt

Kontrollera statusen för framtvingade planer regelbundet

Undvik att byta namn på databaser för frågor med framtvingade planer

Använda Query Store på verksamhetskritiska servrar

Använd Query Store i Azure SQL Databasens aktiva geo-replikering

Håll Query Store justerat efter din arbetsbelastning

Relaterat innehåll

Feedback

Ytterligare resurser