快捷導(dǎo)航

SQL Server中的Forwarded Record計(jì)數(shù)器影響IO性能的解決方法

更新時(shí)間：2014年07月07日 11:32:06 投稿：junjie

這篇文章主要介紹了SQL Server中的Forwarded Record計(jì)數(shù)器影響IO性能的解決方法,需要的朋友可以參考下

一、簡介

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

二、存放原理

在SQL Server中，當(dāng)數(shù)據(jù)是以堆的形式存放時(shí)，數(shù)據(jù)是無序的，所有非聚集索引的指針存放指向物理地址的RID。當(dāng)數(shù)據(jù)行中的變長列增長使得原有頁無法容納下數(shù)據(jù)行時(shí)，數(shù)據(jù)將會(huì)移動(dòng)到新的頁中，并在原位置留下一個(gè)指向新頁的指針，這么做的原因是由于使得當(dāng)出現(xiàn)對Record的更新時(shí)，所有非聚集索引的指針不用變動(dòng)。如圖1所示。

圖1.Forwarded Record示意

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

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

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

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í)我們來看該堆表所占用存儲(chǔ)的頁數(shù)，如圖2所示。

圖2.堆表空間占用

此時(shí)對該表進(jìn)行更新，讓原有行增長，產(chǎn)生Forwarded Record，此時(shí)再來看該堆表的存儲(chǔ)。如圖3所示。

圖3.產(chǎn)生8W+的forwarded record

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

圖4.不該產(chǎn)生的額外IO開銷