Does statistics update cause a recompile?
This my “statistics series” blog. See “Statistics blogs reference” at end of this blog.
In this blog, I will talk two scenarios related to recompile in conjunction with statistics update. A statement can be recompiled for two categories of reasons. First category is related to correctness (such as schema change). Another category is related to plan optimality. Statistics update related recompile falls into second category.
If I were to ask you a question “Does statistics update cause recompile for a query referencing the table?”, what would your answer be? In most cases, the answer is YES! However there are a couple of scenarios where recompile is not necessary. In other words, a query won’t recompile even you have updated statistics for the tables being accessed. We actually got users who called in and inquired about the behaviors from time to time.
Scenario 1 – trivial plan
When a plan is trivial, it’s unnecessary to recompile the query even statistics has been updated. Optimizer generates trivial plan for very simple queries (usually referencing a single table). In XML plan, you will see statementOptmLevel="TRIVIAL". In such case, it’s futile and you won't get a better or different plan.
Let’s see this in action. In the script below, I created a table and two procedures (p_test1 and p_test2). p_test1 has a very simple statement. I execute them once so that the plans will be cached. Then one row is inserted (this is very important as it will be explained in the 2nd scenario). Statistics then is updated.
use tempdb
go
if object_id ('t') is not null drop table t
go
create table t(c1 int)
go
create procedure p_test1 @p1 int
as
select c1 from t where c1 = @p1
go
create procedure p_test2 @p1 int
as
select t1.c1 from t t1 join t t2 on t1.c1=t2.c1 where t1.c1 = @p1
go
set nocount on
declare @i int = 0
while @i < 100000
begin
insert into t values (@i)
set @i += 1
end
go
create index ix on t(c1)
go
exec p_test1 12
exec p_test2 12
go
insert into t values (-1)
go
update statistics t
go
I started profiler trace to trace “SQL:StmtRecompile” event followed by running the following queries again
--no recompile because of trivial plan
exec p_test1 12
--recompile because of stats updated with data change and it's not a trivial plan
exec p_test2 12
Note that only the statement from p_test2 produced StmtRecompile event. This is because the statement in p_test1 produced a trivial plan. Recompile would be futile anyways.
Scenario 2 –no data change
In this scenario, the plan can be non-trivial plan but it still won’t recompile if the table whose statistics was updated hasn’t got any row modification(insert,delete and update) since last statistics update.
Let’s use the same demo above to illustrate the behavior.
let’s update statistics one more time (update statistics t). Note that I didn’t modify the table. Now run the query (p_test2) again below. Note that no StmtRecompile event was produced. It used the existing plan. In short, if there is no data change, there is no need to recompile.
--no recompile because there is no data change even though stats got updated
exec p_test2 12
Scenario 2 actually has complications. Suppose that you updated statistics yesterday. Today you decided that you need to update statistics with fullscan thinking that it may produce better statistics to benefit queries. But there was no change in data. You may be in for a surprise that SQL still used the same plans without recompileing. In such case, you will need to manually free procedure cache to get rid of the plan.
Statistics blogs reference
- filtered statistics
- statistics update with index rebuild
- partitioned table statistics
- sampling & statistics quality.
Jack LI | Senior Escalation Engineer | Microsoft SQL Server Support