sql-server - Sql Server 201 4's "Hekaton”编译的存储过程是否解决了参数嗅探问题？

Question

SQL Server 2014 的 "Hekaton" in-memory table optimization宣称:“存储过程中业务逻辑的 native 编译。”然而，由于 SQL Server 2012 及更早版本中的“参数嗅探”(请参阅​​ here 和 here )问题，我一直被迫使用 OPTIMIZE FOR UNKNOWN 来设计大部分存储过程。 (或其等价物)。这有效地防止查询计划被缓存，并强制 SQL Server 在每次运行查询时重新编译/重新优化查询。由于 Hekaton 的性能提升很大一部分来自于重用 native 编译查询，SQL Server 2014 是否会采取任何措施来解决参数嗅探问题，以便我实际上可以使用编译查询？

Answer 1

解释型 Transact-SQL 存储过程是在第一次执行时编译的，与 native 编译(又名 Hekaton)存储过程不同， native 编译(又名 Hekaton)存储过程是在创建时编译的(因此，查询执行计划是在创建时确定的)。当在调用时编译解释存储过程时，优化器在生成执行计划时将使用为此调用提供的参数值。编译期间对参数的这种使用称为参数嗅探。

参数嗅探不用于编译 native 编译的存储过程。存储过程的所有参数都被视为具有未知值。

作为解决方法，您可以使用 OPTIMIZE FOR 指示查询优化器在编译过程时对变量/参数使用特定值。