SQL Server中的IO效能殺手Forwarded record

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

 

存放原理

    在SQL Server中，當資料是以堆的形式存放時，資料是無序的，所有非聚集索引的指標存放指向實體地址的RID。當資料行中的變長列增長使得原有頁無法容納下資料行時，資料將會移動到新的頁中，並在原位置留下一個指向新頁的指標，這麼做的原因是由於使得當出現對Record的更新時，所有非聚集索引的指標不用變動。如圖1所示。

    這種由於資料更新，只在原有位置留下指標指向新資料頁存放位置行，就是所謂的Forwarded Record。

 

Forwarded Record如何影響IO效能？

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

CREATE TABLE dbo.HeapTest ( id INT, col1 VARCHAR(800) )

DECLARE @index INT
SET @index = 0
BEGIN TRAN
WHILE @index 

    透過程式碼清單1建立測試表，並迴圈插入10萬資料。此時我們來看該堆表所佔用儲存的頁數，如圖2所示。
 
    此時對該表進行更新，讓原有行增長，產生Forwarded Record，此時再來看該堆表的儲存。如圖3所示。
 
    此時我們注意到，雖然資料僅僅佔到590頁，但存在8W+的forwarded record，如果我們對該表進行掃描，則會看到雖然僅僅只有590頁，但需要8W+的邏輯IO，大大提升了對IO的開銷壓力，此外由於forwarded record頁與原頁往往不物理連續，因此對IOPS也存在挑戰。如圖4所示。
 
    而上面查詢反映到效能計數器中，則呈現為如圖5所示的結果。
 
如何解決
    看到Forwarded Record計數器，就說明資料庫中存在堆表，在OLTP系統中，所有的表上都應該有聚集索引。因此可以透過在表上增加聚集索引來解決該問題。
    通常來講，只有只寫不讀的表設定為堆表比較合適，但如果看到存在Forwarded Reocord，則說明堆表上存在讀操作，那麼找到該堆表，找一個合適的維護視窗時間建立聚集索引則是比較理想的選擇。
    如果由於其他原因無法建立聚集索引，則可以對堆表進行表重建。