我遇到了一个问题，我的一堆表的碎片大约为70%到90%，我已经分析了以下避免表碎片的方法：
- 选择一个簇键来补充表的插入模式
- 不要插入具有随机键值的记录
- 不更新记录以延长记录
- 不更新索引键列
- 注意可能导致页面拆分的功能
- 实施指数填充系数
我发现那些"；避免表碎片化的方法"；这里，这里和这里。
然而，通过阅读本文，我的猜测是SQL SERVER必须做"；某事"；以制作索引"；兼容的"；当创建一个新的时彼此之间。
奇怪的是，在减缓问题之前，70%-90%的碎片就已经存在了
所以，不同的是，我又增加了5个新的指标，这就是经济放缓的时候。为了修复它，我只是为每个表执行了一个ALTER INDEX ALL ON TABLENAME REBUILD;，瞧！查询再次变得超级快速(这些索引已经在QA数据库中进行了测试，所以我猜测问题是由第二个数据库统计/碎片引起的(
ALTER INDEX ALL ON TABLENAME REBUILD
不仅减少了索引上的碎片，还更新了索引的统计信息。与碎片减少相比，更新后的统计数据更有可能解决性能问题。
如果您的数据库很小，或者您的页面预期寿命很高，或者位于固态存储或具有大量磁盘的SAN上，则碎片化极不可能造成严重的性能问题。
如果您有一个专用于数据库文件的旋转磁盘，则可以获得约120MB/s的顺序读取速率，但随机IO读取速率小于10MB/s。这种差异是大多数关于减少碎片化的指导意见的历史基础，而且在很大程度上已经过时了。对于现代存储解决方案(大型SAN和固态存储设备(，所有IO都是随机IO。在现代服务器上，更大的内存大小大大减少了大多数工作负载下数据库文件的物理读取IO量。