MySQL数据库工程师入门实战课程视频教程
4075 人在学
标签: 安全数据分析SQL Server
大家可能都了解SQL Server,但是大家有可能不知道SQL Server中一个隐性的IO性能杀手,今天课课家就来跟大家探讨一下,想要了解这个隐性的IO性能杀手的小伙伴,就要认真的阅读哦!相信你一定可以获得很多知识的。
存放原理
在SQLServer中,当数据是以堆的形式存放时,数据是无序的,所有非聚集索引的指针存放指向物理地址的RID。当数据行中的变长列增长使得原有页无法容纳下数据行时,数据将会移动到新的页中,并在原位置留下一个指向新页的指针,这么做的原因是由于使得当出现对Record的更新时,所有非聚集索引的指针不用变动。如图1所示。
图1.ForwardedRecord示意
这种由于数据更新,只在原有位置留下指针指向新数据页存放位置行,就是所谓的ForwardedRecord。
SQLServer的愿景
许多因素致使产生了信息存储爆炸。有了新的信息类型,例如图片和视频的数字化,和从RFID标签获得的传感器信息,公司的数字信息的数量在急剧增长。遵守规范和全球化的发展要求信息存储的安全性和在任何时候都可用。同时,磁盘存储的成本显著地降低了,使得公司投资的每一美元可以存储更多的数据。用户必须快速的在大量的数据中找到相关的信息。此外,他们想在任何设备上使用这个信息,并且计划每天使用,例如MicrosoftOffice系统应用程序。对数据爆炸和用户期望值的增加的管理为公司制造了许多挑战。
Microsoft数据平台愿景提供了一个解决方案来满足这些需求,这个解决方案就是公司可以使用存储和管理许多数据类型,包括XML、e-mail、时间/日历、文件、文档、地理等等,同时提供一个丰富的服务集合来与数据交互作用:搜索、查询、数据分析、报表、数据整合,和强大的同步功能。用户可以访问从创建到存档于任何设备的信息,从桌面到移动设备的信息
ForwardedRecord如何影响IO性能?
那么ForwardedRecord既然是为了提升性能存在的机制,为什么又会引起性能问题?ForwardedRecord的初衷是为了对堆表进行更新时,堆表上存储位置的变化不会同时更新非聚集索引而产生开销。但对于查找来说,无论是堆表上存在表扫描,还是用于书签查找,都会成倍带来额外的IO开销,下面看一个例子。
CREATETABLEdbo.HeapTest(idINT,col1VARCHAR(800))
DECLARE@indexINT
SET@index=0
BEGINTRAN
WHILE@index<100000
BEGIN
INSERTINTOdbo.HeapTest
(id,col1)
VALUES(@index,NULL)
SET@index=@index+1
END
COMMIT
代码清单1.新建堆表并插入10万条数据
通过代码清单1创建测试表,并循环插入10万数据。此时我们来看该堆表所占用存储的页数,如图2所示。
图2.堆表空间占用
此时对该表进行更新,让原有行增长,产生ForwardedRecord,此时再来看该堆表的存储。如图3所示。
图3.产生8W+的forwardedrecord
此时我们注意到,虽然数据仅仅占到590页,但存在8W+的forwardedrecord,如果我们对该表进行扫描,则会看到虽然仅仅只有590页,但需要8W+的逻辑IO,大大提升了对IO的开销压力,此外由于forwardedrecord页与原页往往不物理连续,因此对IOPS也存在挑战。如图4所示。
图4.不该产生的额外IO开销
而上面查询反映到性能计数器中,则呈现为如图5所示的结果。
图5.ForwardedRecord计数器增长
如何解决
看到ForwardedRecord计数器,就说明数据库中存在堆表,在OLTP系统中,所有的表上都应该有聚集索引。因此可以通过在表上增加聚集索引来解决该问题。
通常来讲,只有只写不读的表设置为堆表比较合适,但如果看到存在ForwardedReocord,则说明堆表上存在读操作,那么找到该堆表,找一个合适的维护窗口时间创建堆表则是比较理想的选择。
结束语:看完文章的小伙伴,有不少收获了吧!如果有什么问题,可以提出来跟大家交流一下,课课家也会在第一时间为你解答的。还想了解更多关于这方面的知识内容,也可以随时登陆课课家哟~