嘿，针对你的场景，我得先纠正一个常见误区：索引重建/重组的决策不该看固定时间，而是得看索引的碎片率。结合你的表情况，具体分析如下：

• 先看你的数据增量：百万级的表，每天新增1000-1500条，仅占总数据量的0.1%-0.15%。如果你的聚集索引是自增ID这类顺序键，新增数据是顺序插入的，那非聚集索引的碎片增长会非常缓慢——除非你的非聚集索引包含大量可变长度列，或者表有频繁的更新/删除操作，否则碎片不会快速累积。

• 绝对没必要每次插入后就重建索引！这完全是过度操作，会额外消耗大量CPU、IO资源，甚至可能锁表影响业务（2008R2的在线重建仅限企业版），反而拖慢系统，远得不偿失。

• 每周重建是个可以尝试的起点，但更科学的做法是先监控碎片率：

  1. 用这个SQL查询查看非聚集索引的碎片情况：

     SELECT 
         OBJECT_NAME(ips.object_id) AS TableName,
         i.name AS IndexName,
         ips.avg_fragmentation_in_percent
     FROM 
         sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('你的表名'), NULL, NULL, 'DETAILED') ips
     JOIN 
         sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id
     WHERE 
         i.type_desc = 'NONCLUSTERED';
     

  2. 按照SQL Server的最佳实践来操作：
     • 碎片率在5%-30%：用ALTER INDEX [索引名] ON [表名] REORGANIZE;——这是在线操作，资源消耗低，适合日常维护。
     • 碎片率超过30%：再考虑ALTER INDEX [索引名] ON [表名] REBUILD;（如果是企业版，可以加ONLINE = ON避免锁表）

• 最后给你几个额外的优化点，比纠结重建频率更有效：

  • 如果报表查询是固定的，直接建覆盖索引，把报表需要的所有列都包含进去，这样查询不用回表，速度会大幅提升，对碎片的敏感度也更低。
  • 确保聚集索引是顺序的（比如自增ID），这样新增数据不会打乱聚集索引的顺序，间接减少非聚集索引的碎片产生。
  • 报表生成前可以先更新统计信息：UPDATE STATISTICS [你的表名];——过时的统计信息会让SQL Server生成糟糕的查询计划，这才是很多报表慢的元凶。

内容的提问来源于stack exchange，提问作者Chintan Shah