SQL Server中一個隱性的IO性能殺手
存放原理
在SQL Server中，當(dāng)數(shù)據(jù)是以堆的形式存放時，數(shù)據(jù)是無序的，所有非聚集索引的指針存放指向物理地址的RID。當(dāng)數(shù)據(jù)行中的變長列增長使得原有頁無法容納下數(shù)據(jù)行時，數(shù)據(jù)將會移動到新的頁中，并在原位置留下一個指向新頁的指針，這么做的原因是由于使得當(dāng)出現(xiàn)對Record的更新時，所有非聚集索引的指針不用變動。如圖1所示。
圖1.Forwarded Record示意
這種由于數(shù)據(jù)更新，只在原有位置留下指針指向新數(shù)據(jù)頁存放位置行，就是所謂的Forwarded Record。
Forwarded Record如何影響IO性能？
那么Forwarded Record既然是為了提升性能存在的機制，為什么又會引起性能問題？Forwarded Record的初衷是為了對堆表進行更新時，堆表上存儲位置的變化不會同時更新非聚集索引而產(chǎn)生開銷。但對于查找來說，無論是堆表上存在表掃描，還是用于書簽查找，都會成倍帶來額外的IO開銷，下面看一個例子。
- CREATE TABLE dbo.HeapTest ( id INT, col1 VARCHAR(800) )
- DECLARE @index INT
- SET @index = 0
- BEGIN TRAN
- WHILE @index < 100000
- BEGIN
- INSERT INTO dbo.HeapTest
- ( id, col1 )
- VALUES ( @index, NULL )
- SET @index = @index + 1
- END
- COMMIT
代碼清單1.新建堆表并插入10萬條數(shù)據(jù)
通過代碼清單1創(chuàng)建測試表，并循環(huán)插入10萬數(shù)據(jù)。此時我們來看該堆表所占用存儲的頁數(shù)，如圖2所示。
圖2.堆表空間占用
此時對該表進行更新，讓原有行增長，產(chǎn)生Forwarded Record，此時再來看該堆表的存儲。如圖3所示。
圖3.產(chǎn)生8W+的forwarded record
此時我們注意到，雖然數(shù)據(jù)僅僅占到590頁，但存在8W+的forwarded record，如果我們對該表進行掃描，則會看到雖然僅僅只有590頁，但需要8W+的邏輯IO，大大提升了對IO的開銷壓力，此外由于forwarded record頁與原頁往往不物理連續(xù)，因此對IOPS也存在挑戰(zhàn)。如圖4所示。
圖4.不該產(chǎn)生的額外IO開銷
而上面查詢反映到性能計數(shù)器中，則呈現(xiàn)為如圖5所示的結(jié)果。
圖5.Forwarded Record計數(shù)器增長
如何解決
看到Forwarded Record計數(shù)器，就說明數(shù)據(jù)庫中存在堆表，在OLTP系統(tǒng)中，所有的表上都應(yīng)該有聚集索引。因此可以通過在表上增加聚集索引來解決該問題。
通常來講，只有只寫不讀的表設(shè)置為堆表比較合適，但如果看到存在Forwarded Reocord，則說明堆表上存在讀操作，那么找到該堆表，找一個合適的維護窗口時間創(chuàng)建堆表則是比較理想的選擇。
如果由于其他原因無法創(chuàng)建聚集索引，則可以對堆表進行表重建。
原文鏈接：http://www.cnblogs.com/CareySon/p/3829019.html
