堆表上的转发记录

今天这篇文章我想谈下堆表上特有的性能问题：转发记录（Forwarding Records）。首先我们要澄清下什么是堆表：堆表就是没有聚集索引定义的表。它对插入新记录非常快，但当你读取数据时非常慢。读取数据会在你的存储子系统上引入随机存取（random I/O) ，有时候当你碰到转发记录，它会进一步降低你的读取性能。

为什么会有转发记录？

当堆表里的记录需要移动到不同的物理位置时，SQL Server使用转发记录。假设你有一个变长列的表，首先你在堆表里插入一些记录，这个时候你没有在变长列里存储任何数据：

-- Create a table to demonstrate forwarding records
CREATE TABLE HeapTable
(
    Col1 INT IDENTITY(1, 1),
    Col2 CHAR(2000),
    Col3 VARCHAR(1000)
)
GO

-- Insert 4 records - those will fit into one page
INSERT INTO HeapTable VALUES
(
    REPLICATE('1', 2000),
    ''
),
(
    REPLICATE('2', 2000),
    ''
),
(
    REPLICATE('3', 2000),
    ''
),
(
    REPLICATE('4', 2000),
    ''
)
GO

当你在变长列执行UPDATE语句时，想象下会发生什么？在那个情况下SQL Server可能需要扩展这个记录，因为记录大小更长了，其他记录必须从同个数据页移走。

-- Let's update the table and expand each row of the table
UPDATE HeapTable
SET Col3 = REPLICATE('5', 1000)
GO

在那个情况下，SQL Server在原始位置留下称为转发记录，它指向记录最终存储的新位置。

SQL Server需要使用这个方法来避免更新同个表上所有非聚集索引。你可能知道，当你在堆表上创建非聚集索引时，在叶子层，非聚集索引指向记录数据存储的物理位置。没有抓发记录的话，所有这些指针都要改变，这会大幅度降低你的性能。

如何修正转发记录？

为了找出表里是否包含转发记录，你可以使用DMF sys.dm_db_index_physical_stats。当你在堆表上调用这个函数并传入DETAILED模式，SQL Server通过forwarded_record_count列告诉你表上的转发记录数。

-- Check the forwarding record count through sys.dm_db_index_physical_stats
SELECT
    index_type_desc,
    page_count, 
    avg_page_space_used_in_percent,
    avg_record_size_in_bytes,
    forwarded_record_count
FROM sys.dm_db_index_physical_stats
(
    DB_ID('ALLOCATIONDB'), 
    OBJECT_ID('HeapTable'),
    NULL, 
    NULL, 
    'DETAILED'
)
GO

可以看到，表上有2条转发记录，在4条记录之外。为了去掉这些转发记录，你可以重建表。

-- Rebuild the heap table to get rid of the Forwarding Records
ALTER TABLE HeapTable REBUILD
GO

再次运行刚才的查询，你会发现转发记录已经消失。

-- Check the forwarding record count through sys.dm_db_index_physical_stats
SELECT
    index_type_desc,
    page_count, 
    avg_page_space_used_in_percent,
    avg_record_size_in_bytes,
    forwarded_record_count
FROM sys.dm_db_index_physical_stats
(
    DB_ID('ALLOCATIONDB'), 
    OBJECT_ID('HeapTable'),
    NULL, 
    NULL, 
    'DETAILED'
)
GO

DBA总会考虑到索引碎片，索引重建和索引重新组织操作。但没有人想过堆表里的转发记录。如果你维护数据库，经常检查下堆表上的转发记录数，保证始终有最好的性能，这是个非常好的想法。

小结

在这个文章里你看到了堆表上转发记录是咋样，它是如何降低的记录读取，因为需要额外的逻辑读。当我为数据库进行健康检查时，我在检查堆表时，总会看下转发记录数。

相信我：数据库里会有巨大数量的堆表，在生产系统里也会有很多转发记录，但DBA们并没意识到这个副作用。作为第一经验，我经常推荐在表上建立聚集索引来避免转发记录。当然在一些特定场景里，例如最后页插入加锁竞争（Last Page Insert Latch Contention），在这里你可以使用堆表来避免这个问题，但大多数情况下，在表上建立聚集索引还是非常有用的。

参考文章：

https://www.sqlpassion.at/archive/2014/09/08/forwarding-records-on-heap-tables/