海量数据索引问题
数据表描述：
数据库一表。表里有3个列做为索引列，数据类型分别是：datetime, char(19), numeric 
针对这3个列有一个聚集索引，一个非聚集索引。
问题描述：
目前库里有上亿条数据，如果查时间比较早的数据，速度相对快一些，但是对于今天刚添加的数据的查询速度就很慢，
测试过程中，如果把索引删除并重新创建，今天的数据的查询速度才会快起来。
为什么会出现这个问题？索引不是可以自动维护的吗？为什么新数据的索引没有作用，一定要重新创建过才会提升速度。
希望大牛赐教。
------解决方案--------------------
由于数据改变，索引会失效，所以要重新创建
------解决方案--------------------
原因可能是
今天变化的数据量还不足以更新统计信息
重建索引之所以能加快查询，一方面是整理了碎片
另一方面就是重建索引的同时更新了 统计信息
而查询计划的准确性要依赖统计信息

这种情况可以做个JOB手动去更新统计信息（时间点和频率要根据系统的使用情况酌情设置）
------解决方案--------------------
如果主要是时间切分的话，用分区会好很多。 

没有用到索引的原因是楼上水哥的信息。 

------解决方案--------------------
如果统计信息定义在实体表，且表格从没有数据变成大于等于1条数据，或者对于小于500行的表，当统计信息第一个列的累计变化大于500以后，或者对于大于500行的表，统计信息第一列累计变化量大于500+(20%*表中总数)以后。即对于大表，只有1/5的数据发生变化时，SQLServer才会更新统计信息。
当表有过亿数据，你可以算一下20%有多少才触发更新
------解决方案--------------------
如果这种情况一直出现，假设查询今天的语句是SQL1，查询以前的语句是SQL2,先看一下两个语句的执行计划是否一致。
如果不一致，说明统计信息导致计划解析有误，可以通过统计信息手动更新或者查询改成存储过程的方式解决。
如果一致，打开STAISTICS IO选项，看一下读取页数差距，如果SQL1多了一些IO读取，说明新加的数据被挤出了内存缓冲区。这时候就要检查数据库上运行的大查询了，看有没有写的不好或没必要运行的大查询，从这方面优化一下，保证需要的数据页一直驻留内存。