这也是为什么很多表创建一列与数据本身无关的列作为主键比如AdventureWorks数据库中的Person.Address表，使用AddressID这个和数据本身无关的列作为聚集索引列，如图6所示。而使用AddressLine1作为主键的话，员工地址的变动则可能造成上面列表的问题。


　　图6.创建和数据本身无关的一列作为聚集索引列

　　好使用自增列作为聚集索引列
　　这个建议也同样推荐创建一个和数据本身无关的自增列作为聚集索引列。我们知道，如果新添加进来的数据如果聚集索引列需要插入当前有序的B树中，则需要移动其它的行来给新插入的行腾出位置。因此可能会造成分页和索引碎片。同样的，还会造成修改非聚集索引的额外负担。而使用自增列，新行的插入则会大大的减少分页和碎片。
　　近我碰到过一个情况。一个表每隔几个月性能奇慢无比，初步查看是由于有大量的索引碎片。可是每隔几个月重建一次索引让我无比厌烦。终我发现，问题是由于当时设计数据库的人员将聚集索引建在了GUID上，而GUID是随机生成的，则可能插入到表的任何位置，从而大大增加了碎片的数量。因此造成上面这种情况。
　　总结
　　本文简单介绍了SQL Server存储的原理和应该规避的几种聚集索引建立情况，但这仅仅是从性能的角度来谈聚集索引的选择。对于聚集索引的选择，还是需要全面的考虑进行决定。