Correct SQL Server TempDB Spills in Query Plans Caused by Outdated Statistics

转载 2016年08月31日 10:24:34


Statistics are an integral part of SQL Server and query performance. In short, the query optimizer uses statistics to create query plans that will improve the overall performance of the queries ran. Each statistic object is created on a list of one or more table columns and includes a histogram displaying the distribution of values in the first column. The histogram can have up to 200 steps, but no more regardless of the number of rows in the column or index. Unfortunately, I have seen a warning in my query plan that reads: "Operator used tempdb to spill data during execution with spill level 1". How do I address this warning?


In this tip we’ll take a look at one specific performance issue that you might find in an execution plan of a query which is "Operator used tempdb to spill data during execution with spill level 1". If you’ve ever noticed the following warning, then this tip is for you:

Operator used tempdb spill data during execution with spill level 1

Within the AdventureWorks2014 DB, I’ll use the following query for my example:

SELECT BusinessEntityID, FirstName, LastName, EmailPromotion
FROM [AdventureWorks2014].[Person].[Person]
WHERE EmailPromotion > 0

Looking at this query I can already tell contention may be present so I’ll go ahead and add a covering index:

ON [Person].[Person] ([EmailPromotion])
INCLUDE ([BusinessEntityID],[FirstName],[LastName])

When adding the index above, statistics were automatically created and updated. Since the addition of this index I’ve added a few thousand rows to the Person table.

Let’s run the query and make sure the “Include Actual Execution Plan” button is selected.

Include Actual Execution Plan in SQL Server Management Studio

After the query executes let’s take a look at the execution plan by clicking on the tab in the Results pane:

SQL Server Management Studio Execution Plan

One of the first things you’ll probably notice is the warning sign on the Sort operation. If we hover our mouse over this operator you’ll see more information including the “Warnings: Operator used tempdb to spill data during the execution with spill level 1”

SQL Server Sort operator that used tempdb instead of memory

These warnings were added to SQL Server Management Studio 2012, so if you’re using an older version you may not see this. The spill data to TempDB warning means that the query was not granted enough memory to finish the operation and spilled over into the TempDB to complete the operation. We all know reading from memory is much faster than reading from disk and this is exactly what is happening here. The query read as much as it could from memory before moving over to the TempDB disk.

Let’s look into this further. Hover over the arrow leading to the Sort operation to view the Actual Number of Rows and Estimated Number of Rows:

Estimated Number of Rows vs Actual Number of Rows has a large discrepancy

Aha! The SQL Server database engine only estimated this query would return 568,136 rows, but we actually returned 1,128,192 rows. Seeing this type of discrepancy usually means that statistics are out of date.

Let’s run DBCC SHOW_STATISTICS against our new index to view the histogram:

DBCC SHOW_STATISTICS ('Person.Person', IX_Person_EmailPromotion_INCLUDES)

DBCC SHOW_STATISTICS for the recently created index

As you can see from the previous screenshot, DBCC SHOW_STATISTICS returns 3 different result sets.

  • General information about the statistics object
  • Density vector
  • Histogram

We’re going to concentrate on the general information and histogram result sets for this tip. As you can see from the general information set, rows equal 319,552 and rows sampled equals 68,991

Density vector for the index with a discrepancy between the rows and rows sampled

When we run the following query you’ll notice that there are a lot more records than the general information results are displaying:

SELECT COUNT(EmailPromotion)
FROM [AdventureWorks2014].[Person].[Person]

Row count

Also, you can see from the column RANGE_HI_KEY, there are 177,518 records where the EmailPromotion column equals 0.

RANGE_HI_KEY values and the associated number of rows in the EQ_ROWS column

If you run the following query, however, you’ll see that 1,428,224 records exist where EmailPromotion is equal to 0:

FROM [AdventureWorks2014].[Person].[Person]
WHERE EmailPromotion = 0

All rows with the EmailPromotion of zero

Let’s update this statistic with FULLSCAN by running the following statement:


Now when we run DBCC SHOW_STATISTICS we’ll notice that rows and rows sampled in the general information results are correct. We’ll also see that 1,428,224 records exist for the RANGE_HI_KEY 0. These are the results we were expecting to get.

Results of Rows and Rows Sampled UPDATE STATISTICS with FULLSCAN

Let’s run our query again and look at the execution plan:

Final query plan with the updated statistics

Yes! The warning is gone.

Next Steps
  • When a query is compiled SQL Server does not look at the data in the table or index. It uses statistics to estimate the number of rows that will be returned and that will determine the execution plan. This is why it’s important to keep statistics updated on a regular basis and included as part of your regular maintenance schedule.


Practical Maintenance Plans in SQL Server

  • 2016年05月04日 09:54
  • 22.24MB
  • 下载

RDS SQL Server - 专题分享 - 巧用执行计划缓存之Single-used plans

原文链接 摘要: # 背景引入 执行计划缓存是SQL Server内存管理中非常重要的特性,这篇系列文章我们探讨执行计划缓存设计中遇到的single-used plans问题,以及如何发现、...

ORA-01555 caused by SQL statement below (Query Duration=38751 sec, SCN: 0x0000.fe5b584a)

今天发现一个报表数据库中SQL运行异常,简单记录一下问题的诊断和解决过程。 问题是在检查ALERT文件时发现的,一个过程运行时间太长而出现了ORA-1555错误。 错误信息: ORA...
  • alsmnmn
  • alsmnmn
  • 2012年07月27日 10:08
  • 1351

Ordering guarantees in SQL Server...(SQLServer中保证排序不被优化,insert into by时插入顺序不对)

原文: Ordering guarantees of queries in...

Sql Server tempdb原理-启动过程解析实践

Sql Server tempdb原理-启动过程解析实践 我们知道在SqlServer实例启动过程中数据库会进行还原(Redo,Undo)然后打开提供服务,但我们知道tempdb是不...

SQL SERVER——TempDB问题查找定位与解决

步骤1.TempDB压力诊断 等待类型诊断 TempDB的争用压力在等待篇中已经简单介绍,等待的表现为 pagelatch_类等待,等待的资源是 “2: X :X ”     tempDB...

SQL Server中tempdb的管理


监测谁用了SQL Server的Tempdb空间

转自: Tempdb 系统数据库是一个全局资源,...

Dissecting SQL Server Execution Plans

  • 2013年06月20日 00:06
  • 31.14MB
  • 下载

SQL Server中TempDB管理(版本存储区的一个example)

您举报文章:Correct SQL Server TempDB Spills in Query Plans Caused by Outdated Statistics