[SQL Server]暫存資料表(#TABLE)引發的重新編譯(資料源統計值更新)

經過前面的2篇實驗,實驗出Ad hoc使用到臨時資料表(#TABLE)每次都會重新編譯,至於預存程序(SP)使用臨時資料表則要視情況而定。上一篇還有一個延伸問題,既然預存程序使用臨時資料表(#TABLE)不一定會觸發重新編譯而更新臨時資料表統計值,如果產生臨時資料表的資料源在第一次編譯之後,資料量變動很大,而臨時資料表要和其他資料表Join,是否會導致SQL Query Optimizer應該正確選擇合併或雜湊連結(Merge/Hash Join)卻選擇巢狀迴圈(Nested Loop)而導致效能問題?

...繼續閱讀 »

[SQL Server][Statistics]統計值(五)重複統計值(Overlapping Statistics)

最近在駐點的客戶端遇到一個很神奇的問題,剛匯入大筆資料的隔天(50%以上的異動量),同事有一支程式跑了很久都沒執行完,想辦法和AP人員清理舊資料、加索引,更新統計值後,程式瞬間秒殺,但過沒多久,同事另一支類似功能的程式又塞住,這次即使更新統計值、清除plan cache 、Recompile SQL都沒效。

...繼續閱讀 »

[SQL Server][Statistics]統計值(四)非同步更新統計值(is_auto_update_stats_async_on)

在SQL2016以前,當自動更新統計值選項啟用後,20% + 500筆是一般資料表觸發重新統計的門檻(RT),資料異動累積量達標後,第一個使用統計值的交易會先更新統計值才完成編譯後再實際執行,在某些資料表比較胖的時候,也許先更新統計值再查詢資料的順序可能就會影響OLTP個案交易的執行效能,此時可以試試非同步更新統計值。

...繼續閱讀 »

[SQL Server][Statistics]統計值(一)看見統計值

去年底的跨年,終於把駐點14個月的專案上線了,這個客戶和幾年前上線的客戶最近都遇上統計值影響效能,來記錄問題,順便重修統計值(Statistics)。

統計值是描述欄位值與索引欄位值的分佈統計,也是SQL Query Optimizer進行基數估計(cardinality estimate)的分析來源,透過基數預估,進而決策出優秀的執行計畫來擷取或更新資料。

統計值統治的範圍包含一般資料表、#臨時資料表以及幾個新的企業版本@資料表變數都有統計值。

...繼續閱讀 »