SQL Server中的Forwarded Record計數器影響IO性能的解決方法

SQL Server中的Forwarded Record計數器影響IO性能的解決方法，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

一、簡介

最近在一個客戶那里注意到一個計數器很高（Forwarded Records/Sec），伴隨著間歇性的磁盤等待隊列的波動。本篇文章分享什么是forwarded record，并從原理上談一談為什么Forwarded record會造成額外的IO。

二、存放原理

在SQL Server中，當數據是以堆的形式存放時，數據是無序的，所有非聚集索引的指針存放指向物理地址的RID。當數據行中的變長列增長使得原有頁無法容納下數據行時，數據將會移動到新的頁中，并在原位置留下一個指向新頁的指針，這么做的原因是由于使得當出現對Record的更新時，所有非聚集索引的指針不用變動。

這種由于數據更新，只在原有位置留下指針指向新數據頁存放位置行，就是所謂的Forwarded Record。

三、Forwarded Record如何影響IO性能？

那么Forwarded Record既然是為了提升性能存在的機制，為什么又會引起性能問題？Forwarded Record的初衷是為了對堆表進行更新時，堆表上存儲位置的變化不會同時更新非聚集索引而產生開銷。但對于查找來說，無論是堆表上存在表掃描，還是用于書簽查找，都會成倍帶來額外的IO開銷，下面看一個例子。

BEGIN TRANWHILE @index < 100000   BEGIN     INSERT INTO dbo.HeapTest        ( id, col1 )    VALUES ( @index, NULL )    SET @index = @index + 1  ENDCOMMIT

代碼清單1.新建堆表并插入10萬條數據

通過代碼清單1創建測試表，并循環插入10萬數據。此時我們來看該堆表所占用存儲的頁數。

此時對該表進行更新，讓原有行增長，產生Forwarded Record，此時再來看該堆表的存儲。

此時我們注意到，雖然數據僅僅占到590頁，但存在8W+的forwarded record，如果我們對該表進行掃描，則會看到雖然僅僅只有590頁，但需要8W+的邏輯IO，大大提升了對IO的開銷壓力，此外由于forwarded record頁與原頁往往不物理連續，因此對IOPS也存在挑戰。

而上面查詢反映到性能計數器中。

四、如何解決

看到Forwarded Record計數器，就說明數據庫中存在堆表，在OLTP系統中，所有的表上都應該有聚集索引。因此可以通過在表上增加聚集索引來解決該問題。

通常來講，只有只寫不讀的表設置為堆表比較合適，但如果看到存在Forwarded Reocord，則說明堆表上存在讀操作，那么找到該堆表，找一個合適的維護窗口時間創建堆表則是比較理想的選擇。

如果由于其他原因無法創建聚集索引，則可以對堆表進行表重建。

關于SQL Server中的Forwarded Record計數器影響IO性能的解決方法問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。