场景描述
生产上有一张核心表,读写比例在8:2左右,发现聚集索引字段顺序不佳,经过测试后,发现调整字段顺序后能提高性能。于是在凌晨调整了聚集字段的顺序,但因为操作失误,将聚集索引调成了非聚集索引。在实际业务压力下,聚集,非聚集索引对性能的变化如下。
类别 |
索引名 |
类型 |
索引字段 |
原索引 |
PK_XXXXXXX |
Primary key,CLustered |
(C1,C2,C3) |
新索引 |
PX_XXXXXXX |
Primary key,Non Clustered |
(C3,C2,C1) |
性能指标变化
1:CheckPoint 情况(蓝线:实际压力,红线:基线)
图1(CheckPoint pages/sec_other)
2:Disk Write Bytes情况
图2(Disk Write Bytes/Sec)
3:服务器wait_Resource情况
在sys.sysprocesses.waitResource中,发现大量等待ALLOC_FREESPACE_CACHE (00000000)
等待类型,该类型反应CheckPoint执行慢,脏页多有关。
解决过程
通过把业务切换到其它服务器,把新索引调整为聚集,业务返回后,性能指标恢复到基线一下。
类别 |
索引名 |
类型 |
索引字段 |
新索引 |
PX_XXXXXXX |
Primary key, Clustered |
(C3,C2,C1) |
故障总结
1:从指标上看,非聚集的Disk Write Bytes/Sec的量比聚集高的多,反而写入更繁忙。有些资料中认为,堆表插入速度比聚集表快,因为考虑到聚集插入时,需要寻找键值插入点,而堆表没有这部分时间消耗。
该故障就是一个非聚集写入变慢的例子。
参考资料:(SQL Server企业级平台管理实践 徐海蔚著 P25)
最近SQL Server产品组在SQL Server 2005上做了一个比较,对比有聚集索引和没有聚集索引的表格,在select,insert,update,delete上的性能。……,但出人意料的是,在Insert这一项上,两者也没什么差别。并没有出现聚集索引,影响Insert速度的现象。所以再次强调,在一个大的表格上一定要建立一个聚集索引。除非你的工作负荷压力测试显示出相反的结果。 |
转载于:https://www.cnblogs.com/iamasqldba/archive/2013/03/15/2961618.html