SQL Server如何固定执行计划

  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';