场景描述
生产上有一张核心表，读写比例在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速度的现象。所以再次强调,在一个大的表格上一定要建立一个聚集索引。除非你的工作负荷压力测试显示出相反的结果。 |