最近负责的项目在客户那出了一个问题
场景:服务端会定期删除过期的数据,可能,客户的服务器器在删除数据的时点,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的统计结果来看,我是不是完全没必要去重构索引了呢?