几百万数据的数据库查询
大半夜的我这有一个很严重的问题一直困扰这我

一个数据库(SQL2008)里面有一张收支明细表:字段如下 
Mark(1=收入,2=支出)

ID(自增)　　　Messages　　　　　　　Mark　　　Money　　　　CreateTime
1　　　　　　您xxxx收入xx元　　　　　　1　　　　10.00　　　　2012-11-01 20:10:10     
2　　　　　　您xxxx支出xx元　　　　　　2　　　　10.00　　　　2012-11-01 21:10:10     
3　　　　　　您xxxx收入xx元　　　　　　1　　　　10.00　　　　2012-11-01 22:10:10     
4　　　　　　您xxxx收入xx元　　　　　　1　　　　10.00　　　　2012-11-01 23:10:10     
...
2000000 　　您xxxx支出xx元　　　　　　2　　　　10.00　　　　2012-11-01 23:30:10    

这张表每天插入的数据大概是 几十万条数据左右

每30分钟插入一些数据(这个每次插入也有几万),期间还有零零散散的一些插入

问题就出现在这里 每次在插入的时候  执行(简单的SQL)查询就没法查询了  一直显示请求超时直到插入完毕才恢复
数据量小的时候没发现这个问题 直到后面数据量越来越大已经到了200多万了  真的是查询也费尽插入更费劲

还有操作数据库用的普通的 ADO 希望这里有接触过百万数据的高手指点下  没接触的也可以帮帮忙 

帮忙给出解决方案
------最佳解决方案--------------------

select * from t1 WITH(NOLOCK) 

不怕跳读或者是重复读的话，这就是可行的方案之一了
其实也有过应用，跟你情况一样，一边拉数据过来，一边业务操作，人家千万级的系统就是这样搞的。
------其他解决方案--------------------
你用存储过程了么？
存储过程执行速度比普通T-SQL要快
你可以试一试
------其他解决方案--------------------
这可是数据库板块啊  怎么没几个人帮忙啊
------其他解决方案--------------------
1、考虑是否有必要每次返回大量数据，这样会造成严重的压力。
2、改用存储过程，好处就不说了
3、检查你的查询语句，特别是where子句、索引。
------其他解决方案--------------------
不应该吧。 数据量也不是很大啊 
还有就是 Messages　这个字段设计的有点看不懂，是不是多余了？
------其他解决方案--------------------
插入用存储过程，查询也用存储过程（分页）

还嫌慢，插入用BULK 
------其他解决方案--------------------
按常理来说，业务处理对数据来说是后置的
因为你不大可能在插入数据的时候就去对这些数据进行业务处理，
------其他解决方案--------------------
但是聚集索引设置的合理的话，也有避免跳读或者重复读

with（nolock）住sql后，发生跳读或者重复读是理论上存在的一种可能性，至今还没在生产环境发现过
------其他解决方案--------------------
你的查询语句是什么？执行计划是什么？
------其他解决方案--------------------
读写分离吧。