还有一个问题，当表中300万数据，我对某些字段建立了非聚合索引，查询很快，但当表中又增加100万，200万数据时，查询又慢，我把索引删除，然后重新建立，查询速度有快，所以想请问，非聚合索引是不是需要经常维护重建？那聚合索引是否也需要经常维护重建呢？
先回答你这个问题，常见情况：1、统计信息缺乏维护，或者自动更新统计信息的选项被关闭了。2、索引设计不合理，插入100万数据之后碎片增长非常快，碎片过多导致性能慢，重建之后碎片减少，速度提升。
如果你的查询是用了*号，或者可以换成列名但是列名其实也非常多，那么可能会引起键值查找。不过键值查找不一定就是性能问题，还要看你查询的相对数量，
对于查询：
Where A='条件1' and D>'时间1' and D<'时间2' 这个你可以用这个公式算一下：
select 1.0/distinct a from tb
select 1.0/distinct d from tb
上面的结果中，那个越小，就把那个作为索引的第一列，这里建议建一个复合索引，至于是A在第一列还是D在第一列就要算一下。另外由于A是字符型，最好统计一下最大、最小及平均长度，如果幅度不高，假设A的实际数据长度是15~20，那么建议换成char(20)，如果幅度很大，从1~50都有可能，那么保留varchar
D中，在保证数据能正确反映业务需求的情况下，使用存储空间越小的日期类型越好。比如smalldatetime等。这样你的索引和数据存储空间都小，逻辑IO也相对较少。
对于更新：
B,C做复合索引即可，列的次序和查询部分相同。由于E/F是需要更新的列，不建议加索引。
至于聚集索引，如果你的表有代理键，比如自增ID、GUID等，那可以作为主键（主键默认就是聚集索引），如果没有的话，找一个或者几个能唯一标识每一行的列作为主键。
在给你更多不知道有用无用的建议之前，先要你提供更多信息，比如SQL Server版本、具体数据量。不要靠一个多字，这个没有标准，我接触过2亿的单表，也听过别人把过万的表称为大表。另外在不涉及商业机密的前提下，把你知道的信息都给出来，比如服务器配置、使用的程序语言，系统拿来干嘛的等等。
关机看书，明天早上起来再看，回复记得引用一下
