我的系统有一个新闻表，每天都要录入1千条左右数据，现在用了两年多了，有几百万条了可能，于是销售说，现在打开速度感觉越来越慢了，我觉得可能是这个表里数据量越来越大的原因
1 是不是重新建一下索引速度会好很多？怎么重新建索引呢？
2 另外我担心的是，数据过分增长，以后这个表会不会撑不下，或者无论怎么优化速度都不行，那到时候怎么解决呢？
3 另外表结构是这样的
id name content keywords inputtime
我前台查询时是根据id查询的，后台是根据inputtime between starttime and endtime来查询的，这个starttime ，endtime是我们的编辑输入的日期
id是主键，已经是自增的了，我是不是也把inputtime也建立一个索引，这样后台编辑查询时是不是会快些呢，给inputtime建立索引后，前台根据id查询时，这个inputtime索引不会影响前台查询速度吧？
4 就目前的越来越慢的情况，怎么解决呢？
------解决方案--------------------
我脸皮厚点,先来.欢迎指正.
1 是不是重新建一下索引速度会好很多？怎么重新建索引呢？
--------
我想应该是.
DBCC DBREINDEX
重建指定数据库中表的一个或多个索引。
语法
DBCC DBREINDEX
( [ 'database.owner.table_name '
[ , index_name
[ , fillfactor ]
]
]
) [ WITH NO_INFOMSGS ]
2 另外我担心的是，数据过分增长，以后这个表会不会撑不下，或者无论怎么优化速度都不行，那到时候怎么解决呢？
-------------
设置历史表,有的数据是有时效性的,把他保存的另外的表里面,并删除这个表的这些内容,以待后查
3 另外表结构是这样的
id name content keywords inputtime
我前台查询时是根据id查询的，后台是根据inputtime between starttime and endtime来查询的，这个starttime ，endtime是我们的编辑输入的日期
id是主键，已经是自增的了，我是不是也把inputtime也建立一个索引，这样后台编辑查询时是不是会快些呢，给inputtime建立索引后，前台根据id查询时，这个inputtime索引不会影响前台查询速度吧？
-----------------------
我想不会.
4 就目前的越来越慢的情况，怎么解决呢？
-----------------
清除部分数据.同二
------解决方案--------------------
每年一个库，类似用友金蝶，采用帐套的处理方式。
------解决方案--------------------
inputtime 建立索引
做索引定时维护作业
------解决方案--------------------
我建议LZ对现在的表进行“分割”。
即按照主键id进行分割，把一个原先很大的表分成若干个小的表，从而提高相应的性能。
------解决方案--------------------
帐套的处理方式是什么意思？
它应该是指每一年建立一套帐.