每天需要插入大约3-4万条数据。（预计1年是1200W左右）
现在的问题是，同样的SQL语句（进行了一系列的求和，GROUP BY）。比如几天导入了9.14的数据，我查9.14的，就非常慢。
而查9.13，或者之前的就很快，（每周1,3,5会由计划任务更新索引，更新统计信息）几乎是秒出。
但如果9.14导完数据后，对主表进行重建索引
DECLARE @sql NVARCHAR(MAX)
SELECT @sql=ISNULL(@sql,'')+'ALTER INDEX ['+i.name+'] ON '+OBJECT_NAME(i.[object_id])+' REBUILD PARTITION = ALL;
' FROM sys.indexes AS i
WHERE i.[object_id]=OBJECT_ID('balance') -
PRINT @sql
EXEC(@sql)
然后更新统计信息
update STATISTICS balance with fullscan
有了这2步操作后，就可以秒出。
请教大家一下，这个统计信息，更新索引，执行的频率应该是多少？像我这样，每天4W的记录insert,是否应该每天在插入记录后，
执行重建索引，然后更新统计信息（用上边的语句）？
3 个解决方案
#1
能解决的，都不是问题。既然你知道这样可以解决，那你还犹豫什么？
不过需要指出的是：重建索引这个过程其实已经把统计信息更新了，不需要再更新统计信息
不过需要指出的是：重建索引这个过程其实已经把统计信息更新了，不需要再更新统计信息
#2
其实我想明确的是，究竟在什么样的条件下，要更新统计信息，仅3w条记录的插入，就会有这么大的查询速度影响吗？
还有个问题，有的时候，重建索引好像没有效果，一定要更新统计信息。
而且 要 update STATISTICS balance with fullscan ， update STATISTICS balance也不行
还有个问题，有的时候，重建索引好像没有效果，一定要更新统计信息。
而且 要 update STATISTICS balance with fullscan ， update STATISTICS balance也不行
#3
可以用计划定时更新统计信息
#1
能解决的，都不是问题。既然你知道这样可以解决，那你还犹豫什么？
不过需要指出的是：重建索引这个过程其实已经把统计信息更新了，不需要再更新统计信息
不过需要指出的是：重建索引这个过程其实已经把统计信息更新了，不需要再更新统计信息
#2
其实我想明确的是，究竟在什么样的条件下，要更新统计信息，仅3w条记录的插入，就会有这么大的查询速度影响吗？
还有个问题，有的时候，重建索引好像没有效果，一定要更新统计信息。
而且 要 update STATISTICS balance with fullscan ， update STATISTICS balance也不行
还有个问题，有的时候，重建索引好像没有效果，一定要更新统计信息。
而且 要 update STATISTICS balance with fullscan ， update STATISTICS balance也不行
#3
可以用计划定时更新统计信息