SQL Server 其實從SQL Server 2005開始，也提供了類似ORACLE中固定執行計划的功能，只是好像很少人使用這個功能。當然在SQL Server中不叫"固定執行計划"這個概念，而是叫"執行計划指南"（Plan Guide 很多翻譯是計划指南，個人覺得執行計划指南稍好一些）。當然兩者雖然概念與命名不同，實質上它們所說的是相同的事情，當然商業包裝是很常見的事情。個人還是覺得“固定執行計划”這個概念叫起來順口,通俗易懂，執行計划指南（Plan Guide）叫起來老感覺非常拗口，不知所雲（后面會在這兩個概念切換，你知道我所說的是一件事情就好）。其實我以前也很少使用這些功能，直到最近在SQL Server 2014數據庫中使用固定執行計划解決了幾個SQL的性能問題，所以覺得還是有必要總結、歸納一下。
為什么要固定執行計划？
為什么要使用固定執行計划（Plan Guid）呢？ 個人簡單的從下面幾個方面介紹一下，如有不足，敬請指正。個人也是在探索當中。
由於一些特殊原因（例如Parameter Sniffing、統計信息的變化或采樣比例低造成的統計信息出現偏差、或其他像SQL Server 2014新的基數評估（Cardinality Estimator）特性引起優化器選擇不合適的JOIN操作等等），導致某個SQL的執行計划出現很大偏差，當數據庫優化器為SQL選擇了一個糟糕的執行計划時，就可能出現嚴重性能問題，我就碰到過這樣一個例子，在SQL Server 2014中，有一個SQL的執行頻率較頻繁，有時候優化器突然選擇了一個較差的執行計划時，這時就會出現嚴重的性能問題。所以，這個時候，我們就必須使用Plan Guide固定這個執行計划，從而讓優化器使用正確的執行計划，從而解決這樣的性能問題。
另外一方面，因為優化器生成執行計划本身是很復雜的過程，我們所能干涉的不多，最多使用HINT提示來改變執行計划。而且優化器基於一些算法和開銷考慮，也有可能生成的執行計划不是最優執行計划，而Plan Guid是DBA管理數據庫的一件利器，如果你發現了一個比當前更好的執行計划，也能使用執行計划指南固定這個SQL的執行計划。當然這種情況非常、非常少，至少我在生產環境使用得不多。
有時候,某個系統是購買供應商的，你發現數據庫里面有大量幾乎相同的SQL解析，然后緩存了，其實你發現這些SQL完全可以只解析一次，完全可以參數化，沒有必要大量解析。但是現在供應商沒有提供技術支持了，不可能去優化代碼里面的SQL語句，那么你也可以使用執行計划指南來幫你解決這個問題。
還有就是使用Plan Guide來調優，對比不同的執行計划的優劣。當然應該還有一些其它應用場景，只是我沒有碰到過而已。
如何固定執行計划？
Plan Guide主要用到下面幾個存儲，關於這些系統存儲過程的使用方法、功能介紹，官方文檔有詳細的介紹。在此就不畫蛇添足了。
sys.sp_create_plan_guide,
sys.sp_create_plan_guide_from_handle,
sys.sp_control_plan_guide
下面我們還是看看一些應用場景案例吧！構造一個合適、貼切的例子實在是太花精力和時間，生產環境案例又不能搬出來，我們先來看看官方文檔提供的例子吧，如下SQL所示，在測試數據庫AdventureWorks2014,該SQL使用Nested Loop關聯兩個表
SELECT COUNT(*) AS c
FROM Sales.SalesOrderHeader AS h
INNER JOIN Sales.SalesOrderDetail AS d
ON h.SalesOrderID = d.SalesOrderID
WHERE h.OrderDate >= '20000101' AND h.OrderDate <='20050101';
假如（注意這里是假設）發現如果這個SQL中，兩個表使用MERGE JOIN的方式，效率更高，那么我們可以使用sp_create_plan_guide來創建執行計划指南（固定執行計划），如下所示
EXEC sp_create_plan_guide
@name = N'my_table_jon_guid',
@stmt = N'SELECT COUNT(*) AS c
FROM Sales.SalesOrderHeader AS h
INNER JOIN Sales.SalesOrderDetail AS d
ON h.SalesOrderID = d.SalesOrderID
WHERE h.OrderDate >= ''20000101'' AND h.OrderDate <=''20050101'';',
@type = N'SQL',
@module_or_batch = NULL,
@params = NULL,
@hints = N'OPTION (MERGE JOIN)';
那么此時再執行這個SQL時，你就會發現執行計划就會變成Merge Join方式了。 這樣好過在SQL Server中使用HINT，為什么呢？ 有可能這個SQL是寫死在應用程序里面，如果以后這個執行計划變成了一個糟糕的執行計划，維護的成本非常高（一方面如果沒有記錄，需要耗費精力去定位、查找這段SQL，另外一方面，DBA是沒有權限接觸這些應用程序代碼的，可能需要你溝通、協調開發人員、運維人員。耗費無數的時間、精力.....,還有可能其他接手維護的人不了解情況等等），而使用執行計划指南，那么你查找、禁用、刪除這個執行計划指南即可。非常方便、高效，也許你一分鍾就能搞定，如果是Hint，說不定處理完，需要幾天，想必這樣的耗費精力溝通、協調的事情很多人都遇到過。
SELECT COUNT(*) AS c
FROM Sales.SalesOrderHeader AS h
INNER MERGE JOIN Sales.SalesOrderDetail AS d
ON h.SalesOrderID = d.SalesOrderID
WHERE h.OrderDate >= '20000101' AND h.OrderDate <='20050101';
另外，我們再來構造一個例子，模擬系統里面出現大量解析的SQL語句的案例，如下所示
USE AdventureWorks2014;
GO
SET NOCOUNT ON;
GO
DROP TABLE TEST
GO
CREATE TABLE TEST (OBJECT_ID INT, NAME VARCHAR(8));
GO
CREATE INDEX PK_TEST ON TEST(OBJECT_ID);
GO
DECLARE @Index INT =1;
WHILE @Index <= 10000
BEGIN
INSERT INTO TEST
SELECT @Index, 'kerry';
SET @Index = @Index +1;
END
GO
UPDATE STATISTICS TEST WITH FULLSCAN;
GO
構造了上面案例后，我們清空該數據庫所有緩存的執行計划（僅僅是為了干凈的測試環境，避免以前緩存的執行計划影響實驗結果）,生產環境你不能使用DBCC FREEPROCCACHE清空所有緩存的執行計划，但是可以用DBCC FREEPROCCACHE刪除特定的執行計划。
DBCC FREEPROCCACHE;
GO
然后我們開始測試我們的例子，假設系統里面有大量類似的SQL語句，數量驚人（我們僅僅測試四個）。如果這個系統是從供應商那里購買的，現在又沒有技術支持和Support的人（或者及時有人Support，但是不嚴重影響使用的情況，人家不想花費精力去優化），沒有人協助你優化這些SQL，你又不能將數據庫參數“參數化”從簡單設置為強制（因為影響太大，而且沒有測試，不確定是否帶來潛在的性能問題）.....
SELECT * FROM TEST WHERE OBJECT_ID=1;
GO
SELECT * FROM TEST WHERE OBJECT_ID=2;
GO
SELECT * FROM TEST WHERE OBJECT_ID=3;
GO
SELECT * FROM TEST WHERE OBJECT_ID=4;
GO
....................................................................
此時查看執行計划,發現緩存了4個執行計划
SELECT qs.sql_handle,
qs.statement_start_offset,
qs.statement_end_offset,
qs.plan_handle,
qs.creation_time,
qs.execution_count,
qs.query_hash,
qs.query_plan_hash,
st.text,
qp.query_plan
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS st
CROSS APPLY sys.dm_exec_text_query_plan(qs.plan_handle, qs.statement_start_offset, qs.statement_end_offset) AS qp
WHERE text LIKE N'%SELECT * FROM TEST WHERE OBJECT_ID%' AND text NOT LIKE 'SELECT qs.sql_handle%';
那么此時，執行計划指南就能發揮其作用了,使用sp_create_plan_guide創建執行計划指南，強制SELECT * FROM TEST WHERE OBJECT_ID=xxx這樣的SQL參數化
DECLARE @stmt nvarchar(max);
DECLARE @params nvarchar(max);
EXEC sp_get_query_template N'SELECT * FROM TEST WHERE OBJECT_ID=1',
@stmt OUTPUT,
@params OUTPUT;
EXEC sp_create_plan_guide N'my_sql_parameter_test',
@stmt,
N'TEMPLATE',
NULL,
@params,
N'OPTION(PARAMETERIZATION FORCED)';
然后我們執行下面命令，清空該數據庫所有緩存的執行計划，然后執行上面四個SQL語句
DBCC FREEPROCCACHE;
GO
SELECT * FROM TEST WHERE OBJECT_ID=1;
SELECT * FROM TEST WHERE OBJECT_ID=2;
SELECT * FROM TEST WHERE OBJECT_ID=3;
SELECT * FROM TEST WHERE OBJECT_ID=4;
你會發現他們全部使用執行計划指南里面的執行計划了。不用多次解析了。
還是使用上面的例子，我們來解決一個Parameter Sniffing（參數嗅探）的問題，在實驗前，我們先刪除前面創建的Plan Guide，以免這個影響測試結果，
EXEC sp_control_plan_guide @operation=N'DROP', @name=N'my_sql_parameter_test';
我們構造一個數據傾斜的案例，這樣方便我們演示
UPDATE dbo.TEST SET OBJECT_ID =1 WHERE OBJECT_ID <=2000;
UPDATE STATISTICS dbo.TEST WITH FULLSCAN;
然后我們創建一個簡單的存儲過程Proc_Parameter_Sniffing
CREATE PROCEDURE Proc_Parameter_Sniffing
( @Object_ID INT)
AS
BEGIN
SELECT * FROM TEST WHERE OBJECT_ID=@Object_ID;
END
GO
接下來，我們清空緩存的執行計划，然后執行存儲過程，參數為1
DBCC FREEPROCCACHE;
GO
EXEC Proc_Parameter_Sniffer 1;
然后我們查看這個存儲過程的實際執行計划，如下所示，將Query_Plan這些XML拷貝出來並格式化
1
<
Batch
>
2
<
Statements
>
3
<
StmtSimple
StatementText
="SELECT * FROM TEST WHERE OBJECT_ID=@Object_ID"
StatementId
="1"
StatementCompId
="3"
StatementType
="SELECT"
RetrievedFromCache
="true"
StatementSubTreeCost
="0.0350227"
StatementEstRows
="2000"
StatementOptmLevel
="FULL"
QueryHash
="0xA99C3EB3A64627F3"
QueryPlanHash
="0x50042F73B31C8535"
StatementOptmEarlyAbortReason
="GoodEnoughPlanFound"
CardinalityEstimationModelVersion
="120"
>
4
<
StatementSetOptions
QUOTED_IDENTIFIER
="true"
ARITHABORT
="true"
CONCAT_NULL_YIELDS_NULL
="true"
ANSI_NULLS
="true"
ANSI_PADDING
="true"
ANSI_WARNINGS
="true"
NUMERIC_ROUNDABORT
="false"
/>
5
<
QueryPlan
CachedPlanSize
="16"
CompileTime
="0"
CompileCPU
="0"
CompileMemory
="152"
>
6
<
MemoryGrantInfo
SerialRequiredMemory
="0"
SerialDesiredMemory
="0"
/>
7
<
OptimizerHardwareDependentProperties
EstimatedAvailableMemoryGrant
="209715"
EstimatedPagesCached
="26214"
EstimatedAvailableDegreeOfParallelism
="2"
MaxCompileMemory
="3112816"
/>
8
<
RelOp
NodeId
="0"
PhysicalOp
="Table Scan"
LogicalOp
="Table Scan"
EstimateRows
="2000"
EstimateIO
="0.0238657"
EstimateCPU
="0.011157"
AvgRowSize
="19"
EstimatedTotalSubtreeCost
="0.0350227"
TableCardinality
="10000"
Parallel
="0"
EstimateRebinds
="0"
EstimateRewinds
="0"
EstimatedExecutionMode
="Row"
>
9
<
OutputList
>
10
<
ColumnReference
Database
="[AdventureWorks2014]"
Schema
="[dbo]"
Table
="[TEST]"
Column
="OBJECT_ID"
/>
11
<
ColumnReference
Database
="[AdventureWorks2014]"
Schema
="[dbo]"
Table
="[TEST]"
Column
="NAME"
/>
12
</
OutputList
>
13
<
TableScan
Ordered
="0"
ForcedIndex
="0"
ForceScan
="0"
NoExpandHint
="0"
Storage
="RowStore"
>
14
<
DefinedValues
>
15
<
DefinedValue
>
16
<
ColumnReference
Database
="[AdventureWorks2014]"
Schema
="[dbo]"
Table
="[TEST]"
Column
="OBJECT_ID"
/>
17
</
DefinedValue
>
18
<
DefinedValue
>
19
<
ColumnReference
Database
="[AdventureWorks2014]"
Schema
="[dbo]"
Table
="[TEST]"
Column
="NAME"
/>
20
</
DefinedValue
>
21
</
DefinedValues
>
22
<
Object
Database
="[AdventureWorks2014]"
Schema
="[dbo]"
Table
="[TEST]"
IndexKind
="Heap"
Storage
="RowStore"
/>
23
<
Predicate
>
24
<
ScalarOperator
ScalarString
="[AdventureWorks2014].[dbo].[TEST].[OBJECT_ID]=[@Object_ID]"
>
25
<
Compare
CompareOp
="EQ"
>
26
<
ScalarOperator
>
27
<
Identifier
>
28
<
ColumnReference
Database
="[AdventureWorks2014]"
Schema
="[dbo]"
Table
="[TEST]"
Column
="OBJECT_ID"
/>
29
</
Identifier
>
30
</
ScalarOperator
>
31
<
ScalarOperator
>
32
<
Identifier
>
33
<
ColumnReference
Column
="@Object_ID"
/>
34
</
Identifier
>
35
</
ScalarOperator
>
36
</
Compare
>
37
</
ScalarOperator
>
38
</
Predicate
>
39
</
TableScan
>
40
</
RelOp
>
41
<
ParameterList
>
42
<
ColumnReference
Column
="@Object_ID"
ParameterCompiledValue
="(1)"
/>
43
</
ParameterList
>
44
</
QueryPlan
>
45
</
StmtSimple
>
46
</
Statements
>
47
</
Batch
>
48
</
BatchSequence
>
49
</
ShowPlanXML
>
![clipboard[1]](/image/aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNzM1NDIvMjAxNzAxLzczNTQyLTIwMTcwMTE4MTEwOTI5NDIxLTExNjYzODA4MjkucG5n.png "clipboard[1]")
如下所示，目前它確實是使用准確的執行計划，進行全表掃描（TableScan)，如果此時使用其它參數（例如下面SQL），就會出現Parameter Sniffer(參數嗅探）問題，這個是因為SQL Server在處理存儲過程的時候，是一次編譯，多次重用，執行計划重用。所以當參數為2500的時候，執行計划依然是進行全表掃描（TableScan），這個時候，全表掃描顯然是一個糟糕的執行計划。
EXEC Proc_Parameter_Sniffer 2001;
而且，大部分數據應該做Index Seek是一個較優的執行計划，只有Object_ID=1這樣的特殊數據，全部掃描才是一個較優的執行計划，假如實際使用環境中，也很少用到Object_ID=1這樣的查詢，那么我們可以固定執行計划，讓其使用參數2001的執行計划
EXEC sp_create_plan_guide
@name = N'parameter_sniffing_guid',
@stmt = N'SELECT * FROM TEST WHERE OBJECT_ID=@Object_ID',
@type = N'OBJECT',
@module_or_batch =N'Proc_Parameter_Sniffing',
@params = NULL,
@hints = N'OPTION(optimize for(@Object_ID=2001))';
然后我們再次調用EXEC Proc_Parameter_Sniffer 1;時，你會發現該SQL的執行計划變更為索引查找了。
![clipboard[2]](/image/aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNzM1NDIvMjAxNzAxLzczNTQyLTIwMTcwMTE4MTEwOTMxNDg0LTEzMDkzMDU2MTgucG5n.png "clipboard[2]")
當然實際生產環境中，情況往往比較復雜，絕不可能有這么簡單、理想的環境出現，往往還需要根據實際情況、權衡利弊，多方考慮才能指定一個折中的方案。具體問題具體分析、不能依葫蘆畫瓢。理論要結合實際情況。
查看執行計划指南
查看執行計划指南非常信息非常簡單，你只需要查詢sys.plan_guides即可。
SELECT * FROM sys.plan_guides;
另外，啟用、禁用、刪除執行計划指南都是通過一個系統存儲過程sys.sp_control_plan_guide來實現的，使用非常簡單。下面僅僅簡單舉幾個例子。sys.sp_control_plan_guide的存儲過程如下,實際上它都是封裝調用了sys.sp_control_plan_guide_int的功能
SET QUOTED_IDENTIFIER ON
SET ANSI_NULLS ON
GO
create procedure sys.sp_control_plan_guide
@operation nvarchar(60),
@name sysname = NULL
as
BEGIN TRANSACTION
declare @return_code int
if( lower(@operation) = 'drop' OR lower(@operation) = 'enable' OR lower(@operation) = 'disable')
exec @return_code = @operation, @name
else
exec @return_code = sys.sp_control_plan_guide_int @operation
if( @return_code = 0 )
begin
if( lower(@operation) = 'drop' OR lower(@operation) = 'drop all')
begin
EXEC %%System().FireTrigger(ID = 238, ID = 27, ID = 0, ID = 0, Value = @name,
ID = -1, ID = 0, ID = 0, Value = NULL, ID = 2,
Value = @operation, Value = @name, Value = NULL, Value = NULL, Value = NULL, Value = NULL, Value = NULL)
end
else
begin
EXEC %%System().FireTrigger(ID = 216, ID = 27, ID = 0, ID = 0, Value = @name,
ID = -1, ID = 0, ID = 0, Value = NULL, ID = 2,
Value = @operation, Value = @name, Value = NULL, Value = NULL, Value = NULL, Value = NULL, Value = NULL)
end
end
COMMIT TRANSACTION
GO
禁用執行計划指南
1：禁用名字為my_sql_plan_test的執行計划指南
USE AdventureWorks2014;
GO
EXEC sp_control_plan_guide @operation=N'DISABLE', @name=N'my_sql_plan_test'
2：禁用所有的執行計划指南
USE AdventureWorks2014;
GO
EXEC sys.sp_control_plan_guide @operation = N'DISABLE ALL';
確切的說，應該是禁用數據庫AdventureWorks2014下所有的執行計划指南。
啟用執行計划指南
1：啟用名字為my_sql_plan_test的執行計划指南
USE AdventureWorks2014;
GO
EXEC sp_control_plan_guide @operation=N'ENABLE', @name=N'my_sql_plan_test';
2：啟用所有的執行計划指南
USE AdventureWorks2014;
GO
EXEC sys.sp_control_plan_guide @operation = N'ENABLE ALL';
確切的說，應該是啟用數據庫AdventureWorks2014下所有被禁用的執行計划指南。
刪除執行計划指南
刪除執行計划指南非常簡單，如下所示
我們首先查看有執行計划指南，找到想要刪除的Plan Guide，例如，我們想刪除命名為my_sql_plan_test的執行計划指南。
EXEC sp_control_plan_guide @operation=N'DROP', @name=N'my_sql_plan_test';
參考資料：
https://technet.microsoft.com/zh-cn/library/ms188255(v=sql.105).aspx
https://technet.microsoft.com/zh-cn/library/bb964726(v=sql.105).aspx