SQL2005,一张表里只有三百万不到的数据,为何查询会超时?希望做过大型数据开发的朋友帮个忙,感激.程序是asp
SQL2005,一张表里只有三百万不到的数据,为何查询会超时?希望做过大型数据开发的朋友帮个忙,感激.
程序是asp.net 2.0
数据库为SQL2005 SP2.
WEB服务器和数据库服务器分开,
WEB服务器: IBM 至强2.8, 4GB内存
数据库服务器: IBM 双至强2.8 4GB内存
现在的数据库大约有6GB,会员表有三十多万条记录,信息表里记录也只有三百万不到.
可是查询记录表的时候竟然会超时!
数据库的设计和程序设计已是竭尽我所掌握知识规划的最优.所以这个问题我很难想明白.
以下几个细节我想是需要交待的:
一,WEB服务器CPU占用几乎为0,内存占用1GB不到.数据库服务器的内存占用一直保持在3.3GB左右.CPU占用在50%以下起伏.
二,列表数据显示用的是SQL2005的通用分页存储过程,号称千万数量级的.
三,不做关键字词查询,有时还是很正常,每一页都能够快速显示.但大部份时间却会提示超时,就好像有什么东西堵住了,只要通一下,就会正常一样.
但关键字查询的话基本上就超时.另:关键字查询的字段为标题字段,已建有索引.
四,我也不知道怎么说了,三百万的数据我想怎么样也不该是什么大型数据吧,应该能很轻松应付才对,但不知道为何会这样.
希望有经验的朋友能给建议,感激不尽.
[解决办法]
超时时间是多少
300w的话，再复杂的（不要变态的）20秒以内肯定能出来
查询同时是否有增删减操作？
[解决办法]
查询同时是否有增删减操作？
[解决办法]
让系统自动优化下看看
在Management Studio里写下执行慢的语句，然后 查询菜单 - 在数据库引擎优化顾问中查询 ...
[解决办法]
以下几个细节我想是需要交待的:
一,WEB服务器CPU占用几乎为0,内存占用1GB不到.数据库服务器的内存占用一直保持在3.3GB左右.CPU占用在50%以下起伏.
二,列表数据显示用的是SQL2005的通用分页存储过程,号称千万数量级的.
三,不做关键字词查询,有时还是很正常,每一页都能够快速显示.但大部份时间却会提示超时,就好像有什么东西堵住了,只要通一下,就会正常一样.
但关键字查询的话基本上就超时.另:关键字查询的字段为标题字段,已建有索引.
四,我也不知道怎么说了,三百万的数据我想怎么样也不该是什么大型数据吧,应该能很轻松应付才对,但不知道为何会这样.
希望有经验的朋友能给建议,感激不尽.
1.sql server profiler该出场了。
将结果保存到一个表，然后分析，找出耗时的sql语句。
然后优化之
2.用sp_who2 active 查看blkby列是否有值，如果有，比如为15,那么inputbuffer(15)，看看是谁堵了数据库
3.DB server使用计数器
4.内存有点小。
[解决办法]
你可以把超时的sql语句直接放到查询分析器里去执行，看看要多久啦
一般都是数据库堵塞造成的。
[解决办法]
回家先[color=#FFFFFF] [/color]
[解决办法]
4gb我觉得不小了,我还拿着搞千万级的东西呢
看情况我认为是你sql语句的问题了
[解决办法]
对象数据源分页,适当缓存.
建好索引.
做好查询优化.
[解决办法]
[解决办法]select count(*) from nic_purvey 是多少?
select count(*) from nic_purvey where pur_state>0 是多少?
[解决办法]pur_state有索引吗?
[解决办法][解决办法]重建一下索引,
按照你说的情况,如果是关键字查询,
第一次就会超时,以后就会好转,
估计是你的索引有碎片,
[解决办法]还有就是增加连接超时,因为第一次查询的时候会编译你的语句,所以耗时会长一些..
[解决办法]日期上建了聚合索引,然后以日期做为查询条件会有2分钟?
[解决办法]这表过200W了??
[解决办法]这样三言两语都能解决问题，除非是碰巧吧
建议叫公司花点银子，请人上门综合诊断
最好是请我，呵呵
[解决办法]我免费给处理 ~ 可以远程 ~ 免费
------解决方案--------------------
数据库设计，索引，查询语句，数据库部署。。。
太多考虑了，
表示关注！
[解决办法]靠,真是浪费了这么好的服务器,我用普通PC做服务器,1000多W笔资料用时间做索引查询一个月的资料都只要几S钟,楼主的建议你调整索引顺序,索引顺序对查询速度有决定性的影响,这个大家可能不大清楚吧.查询条件建议都建立索引,条件用得最频繁的放到第一位.这是个人的经验之谈.不纺试试,还有SQL语句的好坏对查询同样影响非常大,建议楼主把SQL语句贴出来让大家诊断诊断
[解决办法]我记得我有次查询一条记录查询到了死机。但查询三条以上的记录，几秒就搞定，，，真不懂查询分析器了。。。。
[解决办法]将ado连接的查询时间设长.
属性CommandTimeout由默认的30改大(如60)
[解决办法]1、建立跟踪，看看你查询超时的是什么语句
2、查看锁，是否存在表锁，存在的话，仔细检查，SQL语句
[解决办法]数据库设计，索引，查询语句，数据库部署。。。
太多考虑了，
表示关注！
[解决办法]select * from nic_purvey where pur_date>'2008-6-17' 耗时是二分多,而且pur_date上还是聚合索引.
索引碎片导致?
[解决办法]不知道
帮你顶了
不知道
帮你顶了
不知道
帮你顶了
不知道
帮你顶了
[解决办法]楼主，给出nic_purvey 的表结构吧.
[解决办法]检查一下是否有死锁。
[解决办法][解决办法]把语句复制到查询分析器，然后 Ctrl + L 看看执行计划，是否用的上你建的索引
怀疑是索引没有用到
[解决办法]e[align=left][/align]
[解决办法]楼主可以参考：
《MS SQL Server查询优化方法》
http://www.cndw.com/tech/data/2006031819362.asp
[解决办法]唯一让有点怀疑的地方是那个ntext字段，里面储存的内容有多少?
至於是不是由於锁定引起的问题这倒容易排除，将Transcation Isolation Level降低一些，看查询速度会不会加快，如果
速度明显加快，那应该是锁引起的问题 ，像这样:
SET Transaction Isolation level Read Uncommitted
select * from nic_purvey where pur_date>'2008-6-17'
---
另外，帮你算一下，你的表结构大小将近400byte，不算上ntext字段的内容，select出3万多笔资料将近就是12m的大小。
如果ntext中的内容比较大，那这个数据也是比较恐怖的，所以另外再检查一下你网络是否有问题。
[解决办法]除了对表进行查询外，是否实时的对表进行了更新呢，如果堆某个表的查询很频繁，又同事的更新了那个表，这样很容易锁住；
其他的暂时想不出还有什么问题
[解决办法]学习
[解决办法][解决办法]我也学习
[解决办法]对于ntext字段读取时最好不要用到，单条记录时再进行读取
------解决方案--------------------
学习了
[解决办法]用sqlserver profiler看一下sql语句
