查看Execution Plan时，在Sort Operator上，发现一个Warning：Operator used tempdb to spill data during execution with spill level 1
以XML格式查看执行计划，发现一个SpillToTempDb的节点：
<Warnings> <SpillToTempDb SpillLevel="1" /> </Warnings>
Sort Warnings are raised by SQL Server when a sort operation cannot be done in memory and must spill to tempdb.
一，Grant Memory
在 SQL Server 编译查询语句时， Optimizer会 Estimate 查询语句完成Sort或Hash操作所需要的内存（Grant Memory），在语句真正执行时，SQL Server 必须申请到这些内存，否则查询语句不会执行。在查询语句执行的过程中，Grant Memory不会被其他Thread占用，也不会减少，这样就能使每一个查询语句都有一个稳定的内存环境，保证查询语句能够顺利执行。由于Grant Memory是Optimizer在 compile-time预估的值，在查询语句执行时，sort 或 hash操作真正需要的内存（run-time memory），可能大于Grant Memory。对于Index Sort 操作，SQL Server从Buffer Pools申请内测，增加Grant Memory，以避免Spill Data to tempdb，如果是非Index Sort操作，那么SQL Server 为了完成Sort 或Hash 操作，就必须将Sort中间表或Hast Table 的一部分数据溢出到tempdb，在低速的disk中做排序或hash 操作（build hash table 或 probe hash match），降低了查询性能。同时，SQL Server 执行器会抛出Sort Warning 或 Hash Warning，这些信息是在run-time时抛出的，不能通过compile-time 查询计划（sys.dm_exec_query_plan 和 sys.dm_exec_text_query_plan）获取到。
引用《Never Ignore a Sort Warning in SQL Server》：
SQL Server does ask for more memory for an in-progress sort to avoid spilling to TempDB. But (there is always a ‘but’), it is not for regular sorts. It only works for index sorts. The interesting thing here is that it can “steal” from the buffer pool as much memory as it needs, so as to avoid a spill to disk.
1，Query Memory Spills
When you sometimes look at Execution Plans, you can see that the SELECT operator has sometimes a so-called Memory Grant assigned. This Memory Grant is specified in kilobytes and is needed for the query execution, when some operators (like Sort/Hash operators) in the Execution Plans need memory for execution – the so called Query Memory.
This query memory must be granted by SQL Server before the query is actually executed. The Query Optimizer uses the underlying Statistics to determine how much Query Memory must be acquired for a given query. The problem is now, when the Statistics are out-of-date, and SQL Server underestimates the processed rows. In this case, SQL Server will also request to less Query Memory for the given query. But when the query actually executes, the query can’t resize its granted Query Memory, and can’t just request more. The query must operate within the granted Query Memory. In this case, SQL Server has to spill the Sort/Hash-Operation into TempDb, which means that our very fast in-memory operation becomes a very slow physical On-Disk operation. SQL Server Profiler will report those Query Memory Spills through the events Sort Warnings and Hash Warning.
2，Extended Events
hash_warning
Occurs when there is insufficient memory to process the build input of a hash join. This results in either a hash recursion when the build input is partitioned, or a hash bailout when the partitioning of the build input exceeds the maximum recursion level.
sort_warning
Occurs when the sort operation on an executing query does not fit into memory. This event is not generated for sort operations caused by index creation, only for sort operations in a query. (For example, an Order By in a Select statement.) Use this event to identify queries that perform slowly because of the sort operation, particularly when the warning_type = 2, indicating multiple passes over the data were required to sort
3,Hash Join
Before a hash join begins execution, SQL Server tries to estimate how much memory it will need to build its hash table. It uses the cardinality estimate for the size of the build input along with the expected average row size to estimate the memory requirement. To minimize the memory required by the hash join, the optimizer chooses the smaller of the two tables as the build table. SQL Server then tries to reserve sufficient memory to ensure that the hash join can successfully store the entire build table in memory. If SQL Server grants the hash join less memory than it requests or if the estimate is too low, the hash join might run out of memory during the build phase. If the hash join runs out of memory, it begins spilling a small percentage of the total hash table to disk (to a workfile in tempdb). The hash join keeps track of which buckets of the hash table are still in memory and which ones have been spilled to disk. As it reads each new row from the build table, it checks to see whether it hashes to an in-memory or an on-disk bucket. If it hashes to an in-memory bucket, it proceeds as usual. If it hashes to an on-disk bucket, it writes the row to disk. This process of running out of memory and spilling buckets to disk can repeat multiple times until the build phase is complete.
二，在SQL Server 2012中，通过Extended Events来Track memory spills.
--step1,create event session
create event session TrackSortWarning
on server
add event sqlserver.sort_warning
(
action (sqlserver.sql_text)
)
)
add target package0.event_file
(
)
WITH
(
max_memory KB,
event_retention_mode=allow_single_event_loss,
max_dispatch_latency seconds,
startup_state=on
);
--step2, start the event session
--step3,query
;with cte as
(
select object_name,cast(event_data as xml) as event_data
from sys.fn_xe_file_target_read_file('D:\TrackSortWarning*.xel',null,null,null)
)
select event_data.value('(event/@timestamp)[1]','datetime') as [timestamp],
event_data.value('(event/data[@name="sort_warning_type"]/text)[1]','varchar(20)') as sort_warning_type,
event_data.value('(event/action[@name="sql_text"]/value)[1]','varchar(max)') as sql_text
from cte;
三，解决memory spills问题
1，Parameter Sniffing
在查询计划执行时，编译器探测变量的当前值，生成一个对变量的当前值“足够好”的执行计划。
select ... from dbo.dt_test where co1>@var_id option(RECOMPILE);
When sort warnings are caused by parameter sniffing, the solution is to use the RECOMPILE query hint in the stored procedure definition.This option forces the optimizer to regenerate the execution plan for the statement containing the hint, rather than reusing an existing execution plan. The optimizer still sniffs the parameter value, but this process happens whenever a stored procedure is executed, not only for the first invocation. When an execution plan is generated, the optimizer checks the value of the parameter, chooses an optimal execution plan and grants sufficient memory to the appropriate operators.
2，更新Outdated stats
如果没有开启自动更新stats info，那么SQL Server Optimizer根据过期的统计信息生成的执行计划，可能会导致Estimated 数据行数小于actual 数据行数，致使Grant memory 偏小，使用 UPDATE STATISTICS (Transact-SQL) 更新统计信息。
3，建立Index，或使用Searchable Arguments（SARG）重写查询语句
如果查询语句不符合SARG的要求，SQL Server Optimizer无法使用index 或 统计信息，导致Optimizer预估的 “Estimated number of rows" 出现偏差。这种情况，必须重写查询语句，使用SARG。必要时，通过创建index 来动态增加Grant Memory，避免Spill data to tempdb。
推荐阅读《Never Ignore a Sort Warning in SQL Server》
参考文档：
Never Ignore a Sort Warning in SQL Server
Correct SQL Server TempDB Spills in Query Plans Caused by Outdated Statistics
Identifying and Solving Sort Warnings Problems in SQL Server
Operator used tempdb to spill data during execution with spill level