强制参数化（Forced Parameterization）

在SQL Server里简单参数化有很多限制，如果你的SQL语句包含下列任意它不会发生：

JOIN
IN
BULK INSERT
UNION
INTO
DISTINCT
TOP
GROUP BY
HAVING
COMPUTE
Sub Queries

如果你还想让SQL Server进行自动参数化，你可以启用在数据库层启用强制参数化：

1 -- Let's now activate Forced Parameterization on the AdventureWorks2012 database
2 ALTER DATABASE AdventureWorks2012 SET PARAMETERIZATION FORCED
3 GO

在这个情况下，SQL Server总会自动参数化你的SQL语句除掉以下情况：

INSERT … EXECUTE
Prepared SQL Statements
RECOMPILE
COMPUTE

为什么强制参数化总不是个好选择

现在让我们看下SQL Server里的强制参数化。对于AdventureWorks2012数据库，最后的代码已经将它启用强制参数化了。下一步我创建Sales.SalesOrderHeader表的副本，并将数据修正，这样的话在CustomerID列我们会有非线性的数据分布。另外我在那一列也创建了非聚集索引。

 1 -- Create a copy from the Sales.SalesOrderHeader table
 2 SELECT * INTO Sales.SalesOrderHeader2 FROM Sales.SalesOrderHeader
 3 GO
 4  
 5 -- Create a Non-Clustered Index on the CustomerID column
 6 CREATE NONCLUSTERED INDEX idx_CustomerID ON Sales.SalesOrderHeader2(CustomerID)
 7 GO
 8 
 9 -- "Patch" the data in some way, so that the content of the column "CustomerID" is not evenly distributed across the whole table
10 UPDATE Sales.SalesOrderHeader2
11 SET CustomerID = 29675
12 WHERE SalesOrderID < 60000
13 GO

从下图你可以看到：ID为29675的客户有大量的订单，其它客户只有一些订单：

1 SELECT CustomerID,COUNT(SalesOrderID) SaleCount FROM Sales.SalesOrderHeader2
2 GROUP BY CustomerID ORDER BY 2 DESC

在下一步里我执行一个返回CustomerID为22943的所有记录——只有3条记录。因为查询在临界点前，SQL Server选择了有书签查找的执行计划。查询合计生成了3个逻辑读。因为我们对AdventureWorks2012数据库启用了强制参数化，对这个语句SQL Server也会自动参数化，因此执行计划会被后续的查询重用。

1 -- 3 Logical Reads
2 SELECT * FROM Sales.SalesOrderHeader2
3 WHERE CustomerID = 22943 -- Index Seek, returns 1 record
4 GO

我们再来运行另一个查询，返回所有CustomerID为29675的记录。在这个情况下查询返回16343条记录。当你再次看执行计划时，你会看到查询重用了刚才查询的执行计划。

1 SELECT * FROM Sales.SalesOrderHeader2
2 WHERE CustomerID = 29675 
3 GO

这是对的，以为查询自动参数化，SQL Server在计划缓存里找已经缓存的计划。但是重用执行计划并不安全，因为现在我们进行了书签查找16343次——对每一行——反复执行。查询合计生成了16415个逻辑读。使用表扫描的话只要780个逻辑读。

这是强制参数化的副作用。SQL Server不管你执行计划的稳定性。SQL Server值自动参数化你的SQL语句，并反复重用缓存的执行计划。不管这个执行计划有糟糕。因为这是你强制SQL Server只要做的！没有启用强制参数化，SQL Server从不为你自动参数化SQL语句，因为那不安全。

性能问题的根源肯定是强制参数化。这里的根源是你的执行计划包含书签查找。因为书签查找你就没有计划稳定性。计划没有稳定性是说基于你输入参数值你会有不同的执行计划。在这个例子里有时你得到书签查找（临界点前），有时是表扫描（临界点后）。

在这个情况下，如果你修改下你的索引设计，为这个查询定义一个覆盖非聚集索引，性能问题也会消失。这样的话也不需要启用强制参数化，因为使用计划稳定性SQL Server会自动参数化你的SQL语句！

小结

在数据库级别启用强制参数化是个非常危险的事。不管你是否有计划稳定性，SQL Server总会自动参数化你的SQL语句，并反复重用你的执行计划。因此你要知道你的执行计划的详细情况，看看它们是否会引起性能相关的问题。

感谢关注！

参考文章：

https://www.sqlpassion.at/archive/2015/07/27/the-pain-of-forced-parameterization-in-sql-server/