#temp 表中的轉發記錄
我有一個臨時表，我根據連接多次更新（每次幾乎所有行）。我將它保留為一個堆，因為如果我沒有獲得內部循環連接，那麼在每次更新後我都會在執行計劃中得到一個排序。如果我想獲得正確的連接，我加入的其他表也需要有一個唯一索引（即，我在連接後沒有得到排序）。這個答案有助於解釋這個問題：Updating a table effective using JOIN
這只是對為什麼表是堆的解釋。
現在我的問題是：這些轉發的記錄對我的 SP 的性能有多大影響？假設我有 10 次更新，每次更新都會獲得更多轉發記錄。我應該在說五次更新後重建堆臨時表嗎？如何計算重建堆的次數？
所以基本上我的問題是如何處理一個多次更新的表，並且每次更新基本上都會更新特定列的所有行。這是一個報告查詢。
如果我保持表有一個堆，我會得到額外的 IO，如果我創建一個聚集索引，我需要讓所有語句進行內部循環連接，即使我實現了這一點，我仍然會得到頁面拆分……
我還沒有嘗試過，但我正在考慮將字元串列更改為固定長度的列以避免轉發記錄，但這似乎也增加了 IO，至少在開始時……
轉發記錄何時會損害特定查詢的性能這個問題太寬泛而無法回答，並且會根據查詢實際執行的操作而有所不同。
您連結的 DBA.StackExchange 文章中沒有任何地方建議使用堆表，而是顯示如何通過強制使用帶有適當查詢提示的替代****執行計劃來解決性能問題（如果適用）來利用索引表。如果您之前遇到過與該文章的問題相匹配的性能問題，我建議您採納 Paul White 的建議，但無論哪種情況，建議都是為您的表編制索引，尤其是在您經常加入該表的情況下。
或者，Tara Kizer 有一篇關於如何修復轉發記錄的精彩文章，該文章基本上以通過重建表進行臨時修復或通過向其添加****聚集索引來永久修復的建議結束。
如果您仍然堅持將其保留為堆，那麼直接回答“何時”重建表的問題，通常建議根據堆碎片來這樣做。這是一個更容易測量的數字，可用於確定何時是重建表的正確時間。有些人選擇在 20% 碎片後重建，其他人選擇 50%，有些人等到表大部分碎片化，這取決於您的情況以及您針對堆表執行的特定查詢。但是您可以在SQL Server Heaps 及其 Fragmentation中收集有關堆碎片和重建表的更多資訊。