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」編譯存儲過程是否解決參數嗅探問題？

回答

相關問題