Sql Server 2014的“Hekaton”编译存储过程是否解决参数嗅探问题？

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

来源

2013-06-26 Mike

我不知道答案，但考虑到CTP刚出来的时候，那些有机会回答这个问题的人都是NDA，我会说你不太可能得到很快就会有令人满意的答案。这就是说，它可以以任何方式。如果我要把钱投入它，我会说参数嗅探可能总是会成为一个问题，除非他们想出了一种方法来存储不同参数的不同计划。 –

解释的Transact-SQL存储过程是在第一次执行时编译的，与本地编译的（也就是Hekaton）存储过程相比，它们是在创建时编译的（因此查询执行计划是在创建时确定的）。当解释存储过程在调用时被编译时，优化器在生成执行计划时使用为此调用提供的参数值。在编译过程中使用这些参数称为参数嗅探。

参数嗅探不用于编译本地编译的存储过程。存储过程的所有参数都被认为具有UNKNOWN值。

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

来源

2013-10-03 17:26:49 Gjorgji

据我所知，当您创建“本机”存储过程时，它将立即编译为本机代码，并且不会通过查询优化器。所以我不认为“参数嗅探”问题会成为一个问题。

来源

2013-07-10 17:51:07 sha

在过程编译过程中将调用查询优化器，并在此时确定执行计划（即所有调用都将有一个执行计划）。 – Gjorgji

Sql Server 2014的“Hekaton”编译存储过程是否解决参数嗅探问题？

回答

相关问题