日期:2014-05-17  浏览次数:20566 次

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

一个数据库(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后,发生跳读或者重复读是理论上存在的一种可能性,至今还没在生产环境发现过
------其他解决方案--------------------
你的查询语句是什么?执行计划是什么?
------其他解决方案--------------------
读写分离吧。