你的SQL Server碎片真的需要重新构建(Rebuild)或者重新组织(Recognize)吗？

摘要: 变更不是很多，主要用于数据查询的数据库，表结构，个人认为没必要担心磁盘的碎片率有多大

最近负责的项目在客户那出了一个问题

场景：服务端会定期删除过期的数据，可能，客户的服务器器在删除数据的时点，Service down了

问题：删除没有执行，大量数据残留，导致磁盘空间不足，用户的动作执行缓慢，受阻

和领导负责一块研究解决问题的过程中，解决方案是定期删除残留的数据，并压缩日志文件。

同时领导带出了一个索引碎片的问题，说索引碎片会影响大量数据的查询，本来，这个数据库的变更就很少，服务端的操作主要就是查询。

经过试验证明，简单的Select查询， 索引碎片 不会有太大的影响，以下是验证的过程：

1. 新建数据库，模拟应用程序的数据，通过SqlBulkCopy快速插入超过3个月的数据，大概20G。

2. 查看索引碎片率：45%。

3. 通过查询分析+select语句获取了3天，1周，1个月，3个月的数据，统计花费的时间

SET STATISTICS profile ON
SET STATISTICS io ON
SET STATISTICS time ON
go
---你要测试的sql语句
SELECT * FROM [UniversalSchool].[dbo].[Student] where StudentID = 35 AND Datetime BETWEEN cast('2017-01-01 00:00:00.000' as datetime) and cast('2017-04-01 00:00:00.000' as datetime);
SET STATISTICS profile OFF
SET STATISTICS io OFF
SET STATISTICS time OFF
go

结果：

★ 3天
5219 毫秒。

★ 1周
11245 毫秒。

★ 1月
51478 毫秒。

★ 3月
175508 毫秒。

4. 通过以下命令将索引重新构建

sqlcmd -E -S (local)\DBTEST -Q "use  UniversalSchool ;ALTER INDEX ALL ON  Student REBUILD"

5. 查看索引碎片率：0.12%。

6. 再执行第3.步，统计结果

★ 3天
5222 毫秒。

★ 1周
10724 毫秒。

★ 1月
50237 毫秒。

★ 3月
164040 毫秒。

从3和6的统计结果来看，我是不是完全没必要去重构索引了呢？