patternMinor
Why are there multiple plans for query under forced parameterization?
Viewed 0 times
whyarequeryunderforcedformultipleparameterizationthereplans
Problem
I see the following query in an Azure SQL Database (that has Forced Parameterization = FORCED, Parameter Sniffing = ON, and Query Optimizer Fixes = ON) from within Query Store:
It has a large number of plans (17 in the last hour), despite both parameters being integers with identical values in each plan:
Why isn't only one plan being used?
delete from [CMS_WebFarmTask]
where [TaskIsAnonymous] = @0
and [TaskID] not in ( select [TaskID] from [CMS_WebFarmServerTask] )
and [TaskCreated] < dateadd ( minute , @1 , getdate ( ) )It has a large number of plans (17 in the last hour), despite both parameters being integers with identical values in each plan:
Why isn't only one plan being used?
Solution
Forced parameterization <> forced single plan.
However, the Query Store does have a feature to force a single plan if that's what you're after. You can see the button for it right in your screenshot.
But, if your concern is more general as to why you're getting multiple plans in the first place, you should start by making sure the same query is being executed each time. In your case, since you're using
You also need to be aware of the fact that the statistics of the underlying tables could be changing over time as well, which can heavily impact plan estimations. There are lots of other factors that play into it - this article digs deeper into what goes into an execution plan and what can affect them. The database is a living thing and plan changing shouldn't be inherently viewed as a bad thing, unless it is causing obvious performance issues.
However, the Query Store does have a feature to force a single plan if that's what you're after. You can see the button for it right in your screenshot.
But, if your concern is more general as to why you're getting multiple plans in the first place, you should start by making sure the same query is being executed each time. In your case, since you're using
GETDATE(), the query is actually different every time it runs, so I wouldn't expect it to yield the same plan necessarily based on that alone.You also need to be aware of the fact that the statistics of the underlying tables could be changing over time as well, which can heavily impact plan estimations. There are lots of other factors that play into it - this article digs deeper into what goes into an execution plan and what can affect them. The database is a living thing and plan changing shouldn't be inherently viewed as a bad thing, unless it is causing obvious performance issues.
Context
StackExchange Database Administrators Q#225015, answer score: 2
Revisions (0)
No revisions yet.