堆表上的转发记录

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

为什么会有转发记录?

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

 1 -- Create a table to demonstrate forwarding records
 2 CREATE TABLE HeapTable
 3 (
 4     Col1 INT IDENTITY(1, 1),
 5     Col2 CHAR(2000),
 6     Col3 VARCHAR(1000)
 7 )
 8 GO
 9 
10 -- Insert 4 records - those will fit into one page
11 INSERT INTO HeapTable VALUES
12 (
13     REPLICATE('1', 2000),
14     ''
15 ),
16 (
17     REPLICATE('2', 2000),
18     ''
19 ),
20 (
21     REPLICATE('3', 2000),
22     ''
23 ),
24 (
25     REPLICATE('4', 2000),
26     ''
27 )
28 GO

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

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

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

 

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

如何修正转发记录?

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

 1 -- Check the forwarding record count through sys.dm_db_index_physical_stats
 2 SELECT
 3     index_type_desc,
 4     page_count, 
 5     avg_page_space_used_in_percent,
 6     avg_record_size_in_bytes,
 7     forwarded_record_count
 8 FROM sys.dm_db_index_physical_stats
 9 (
10     DB_ID('ALLOCATIONDB'), 
11     OBJECT_ID('HeapTable'),
12     NULL, 
13     NULL, 
14     'DETAILED'
15 )
16 GO

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

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

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

 1 -- Check the forwarding record count through sys.dm_db_index_physical_stats
 2 SELECT
 3     index_type_desc,
 4     page_count, 
 5     avg_page_space_used_in_percent,
 6     avg_record_size_in_bytes,
 7     forwarded_record_count
 8 FROM sys.dm_db_index_physical_stats
 9 (
10     DB_ID('ALLOCATIONDB'), 
11     OBJECT_ID('HeapTable'),
12     NULL, 
13     NULL, 
14     'DETAILED'
15 )
16 GO

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

小结

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

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

参考文章:

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

posted @ 2015-06-24 09:18  Woodytu  阅读(965)  评论(1编辑  收藏  举报