Chování, které popisujete, je často způsobeno nesprávně uloženým plánem dotazů v mezipaměti a/nebo zastaralými statistikami.
Obvykle se vyskytuje, když máte velký počet parametrů v klauzuli WHERE, zejména dlouhý seznam těch, které mají tvar:
(@parameter1 is NULL OR TableColumn1 = @parameter1)
Řekněme, že vyprší platnost plánu dotazů uložených v mezipaměti a proc se zavolá s nereprezentativní sadou parametrů. Plán se pak uloží do mezipaměti pro tento datový profil. ALE, pokud je proces častěji běžný s velmi odlišnou sadou parametrů, plán nemusí být vhodný. Toto je často známé jako „sniffování parametrů“.
Existují způsoby, jak tento problém zmírnit a odstranit, ale mohou zahrnovat kompromisy a záviset na vaší verzi SQL Server. Podívejte se na OPTIMIZE FOR
a OPTIMIZE FOR UNKNOWN
. POKUD (a je to velké if) se proces volá zřídka, ale musí běžet co nejrychleji, můžete jej označit jako OPTION(RECOMPILE)
, abyste vynutili rekompilaci pokaždé, když je volána, ALE nedělejte to u často volaných procesů NEBO bez vyšetřování.
[POZNÁMKA:uvědomte si, které Servisní balíček a kumulativní aktualizace (CU) váš box SQL Server 2008 má, protože logika rekompilace a sniffování parametrů v některých verzích funguje jinak]
Spusťte tento dotaz (od Glenna Berryho), abyste zjistili stav statistik:
-- When were Statistics last updated on all indexes?
SELECT o.name, i.name AS [Index Name],
STATS_DATE(i.[object_id], i.index_id) AS [Statistics Date],
s.auto_created, s.no_recompute, s.user_created, st.row_count
FROM sys.objects AS o WITH (NOLOCK)
INNER JOIN sys.indexes AS i WITH (NOLOCK)
ON o.[object_id] = i.[object_id]
INNER JOIN sys.stats AS s WITH (NOLOCK)
ON i.[object_id] = s.[object_id]
AND i.index_id = s.stats_id
INNER JOIN sys.dm_db_partition_stats AS st WITH (NOLOCK)
ON o.[object_id] = st.[object_id]
AND i.[index_id] = st.[index_id]
WHERE o.[type] = 'U'
ORDER BY STATS_DATE(i.[object_id], i.index_id) ASC OPTION (RECOMPILE);