經過前面的2篇實驗，實驗出Ad hoc使用到臨時資料表(#TABLE)每次都會重新編譯，至於預存程序(SP)使用臨時資料表則要視情況而定。上一篇還有一個延伸問題，既然預存程序使用臨時資料表(#TABLE)不一定會觸發重新編譯而更新臨時資料表統計值，如果產生臨時資料表的資料源在第一次編譯之後，資料量變動很大，而臨時資料表要和其他資料表Join，是否會導致SQL Query Optimizer應該正確選擇合併或雜湊連結(Merge/Hash Join)卻選擇巢狀迴圈(Nested Loop)而導致效能問題?
上一篇筆記了Ad hoc使用暫存資料表(#Table)引發的重新編譯(Recompilations)，過量的重新編譯會增加CPU的負擔，換個方式執行SQL，如果預存程序(Stored Procedure)中使用暫存資料表(#TABLE)會不會造成每次執行就重新編譯?
最近在駐點的客戶端遇到一個很神奇的問題，剛匯入大筆資料的隔天(50%以上的異動量)，同事有一支程式跑了很久都沒執行完，想辦法和AP人員清理舊資料、加索引，更新統計值後，程式瞬間秒殺，但過沒多久，同事另一支類似功能的程式又塞住，這次即使更新統計值、清除plan cache 、Recompile SQL都沒效。
在SQL2016以前，當自動更新統計值選項啟用後，20% + 500筆是一般資料表觸發重新統計的門檻(RT)，資料異動累積量達標後，第一個使用統計值的交易會先更新統計值才完成編譯後再實際執行，在某些資料表比較胖的時候，也許先更新統計值再查詢資料的順序可能就會影響OLTP個案交易的執行效能，此時可以試試非同步更新統計值。
上一篇我們注意到統計值(Statistics)不夠即時可能造成SQL Optimizer無法產生最佳的執行計畫，另外也發現自動更新統計值並不是發生在資料更新的同時，而是發生在更新後第一次使用統計值的SQL指令作編譯前，那麼多少的異動量條件會觸發統計值更新?
去年底上線前的一次系統轉換演練，碰到某支轉檔SQL執行變慢，表象是執行計畫改變(plan change)，進一步找原因則發現是不太即時的統計值造成Query Optimizer產生較差的執行計畫。
去年底的跨年，終於把駐點14個月的專案上線了，這個客戶和幾年前上線的客戶最近都遇上統計值影響效能，來記錄問題，順便重修統計值(Statistics)。
統計值是描述欄位值與索引欄位值的分佈統計，也是SQL Query Optimizer進行基數估計(cardinality estimate)的分析來源，透過基數預估，進而決策出優秀的執行計畫來擷取或更新資料。
統計值統治的範圍包含一般資料表、#臨時資料表以及幾個新的企業版本@資料表變數都有統計值。