w_rose说的不错！我了！1、语句优化 语句优化不是看你的代码少就优化，如明显的例子： select * from 表 where 时间>'1999-1-1' and 时间<'1999-12-31' select * from 表 where year(时间)=1999 哪个快呢？2、索引优化 你的这个表一定有个索引，在使用簇索引查询的时候，区块查询是最快的，如用between，应为他是物理连续的，你应该尽量减少对它的updaet,应为这可以使它物理不连续。非簇索引与物理顺序无关，设计它时必须有高度的可选择性，可以提高查询速度，但对表update的时候这些非簇索引会影响速度，且占用空间大，如果你愿意用空间和修改时间换取速度可以考虑。还有就是你在将索引建好后，定期维护是很重要的，用dbcc showcontig来观察页密度、扫描密度等等，及时用dbcc indexdefrag来整理表或视图的索引,在必要的时候用dbcc dbreindex来重建索引可以受到良好的效果。你的数据库是销售记录应该update的较少，在条件允许的情况下，你在where后的条件尽量扫描索引。3、多服务器群集、分区视图 就是将你的数据水平分割在集群服务器上，这主要看的你访问量，你说你每天上千条数据，你有几个终端？还是B/S结构？如果你数据库不是访问特别大时可以大大减轻对单个数据库服务器的负载
语句优化不是看你的代码少就优化，如明显的例子：
select * from 表 where 时间>'1999-1-1' and 时间<'1999-12-31'
select * from 表 where year(时间)=1999
哪个快呢？2、索引优化
你的这个表一定有个索引，在使用簇索引查询的时候，区块查询是最快的，如用between，应为他是物理连续的，你应该尽量减少对它的updaet,应为这可以使它物理不连续。非簇索引与物理顺序无关，设计它时必须有高度的可选择性，可以提高查询速度，但对表update的时候这些非簇索引会影响速度，且占用空间大，如果你愿意用空间和修改时间换取速度可以考虑。还有就是你在将索引建好后，定期维护是很重要的，用dbcc showcontig来观察页密度、扫描密度等等，及时用dbcc indexdefrag来整理表或视图的索引,在必要的时候用dbcc dbreindex来重建索引可以受到良好的效果。你的数据库是销售记录应该update的较少，在条件允许的情况下，你在where后的条件尽量扫描索引。3、多服务器群集、分区视图
就是将你的数据水平分割在集群服务器上，这主要看的你访问量，你说你每天上千条数据，你有几个终端？还是B/S结构？如果你数据库不是访问特别大时可以大大减轻对单个数据库服务器的负载