SQL SERVER 2005 频繁对一个表进行更新问题

D_Future 2014-01-07 04:19:36

一个表有主键 400条数据，但是更新次数特别频繁，大概1秒几十次，这样会造成什么问题么

现在表现出来的问题就是更新有时耗时长，有时极段，高的时候甚至都能达到几秒

听说有表锁的问题，和这个有关系么

求指导！！求大神！！

好人一生平安！！

...全文

337 19 打赏收藏转发到动态举报

写回复

用AI写文章

19 条回复

切换为时间正序

请发表友善的回复…

发表回复

岩崽先生 2014-01-14

打赏
举报

涉及的表with nolock 下试试

bashen1101 2014-01-14

打赏
举报

也许是聚集索引引起的，看看有没有，删了换非聚集索引试试

我在这儿等你 2014-01-09

打赏
举报

我遇到了一个问题，数据库插入很频繁，1秒可能有几十条或者上百条，和楼主的问题有点类似，期待解答

D_Future 2014-01-09

打赏
举报

引用 14 楼 OrchidCat 的回复:

需要在数据库侧看一下是具体的阻塞或者是锁的情况。就并发判断，lz的这个很可能是锁。还是排队那个事儿，大家都等待着前面的事务完成。另外，lz这种高并发，是否考虑隔离级别的修改。比如使用未提交读

另外，lz这种高并发，是否考虑隔离级别的修改。比如使用未提交读能给点详细的解释么，数据库弄得不是太懂

D_Future 2014-01-09

打赏
举报

引用 16 楼 zgguoqing 的回复:

我遇到了一个问题，数据库插入很频繁，1秒可能有几十条或者上百条，和楼主的问题有点类似，期待解答

以前也是这么调用也没看出现这种情况，但是最近总是出现调用个简单的update居然1秒甚至10秒不知道为什么，数据库这块不是很懂，简单的到时没问题，这种级别的就不知道该怎么办了，我现在主要是去弄如何减少调用，具体这种情况的原理还不清楚，你找的解决办法的时候也告诉我一下谢谢

Mr_Nice 2014-01-07

打赏
举报

需要在数据库侧看一下是具体的阻塞或者是锁的情况。就并发判断，lz的这个很可能是锁。还是排队那个事儿，大家都等待着前面的事务完成。另外，lz这种高并发，是否考虑隔离级别的修改。比如使用未提交读

發糞塗牆 2014-01-07

打赏
举报

查看等待状态是必须的手段

發糞塗牆 2014-01-07

打赏
举报

引用 9 楼 u011371217 的回复:

[quote=引用 4 楼 DBA_Huangzj 的回复:] 你这个情况应该就是锁问题导致的，我觉得改进设计才是王道，具体说说你的情况

引用 7 楼 OrchidCat 的回复:

400行的表，表扫描的速度就非常快。时间长短不一，这个是并发的问题。后面的要等待前面的事务完成。不用等待，就很快完成。需要等待就慢些，简单说就是排队。后面的要排比较久。

引用 6 楼 ap0405140 的回复:

400条数据的表,可不用建索引.

引用 3 楼 yupeigu 的回复:

确实有锁的问题。照理你的表才400条数据，应该不会更新一下，需要好几秒的

我现在是用vc中调用一个存储过程，存储过程中的代码是这样的


    if (@isstate=1)
    update dbo.B_Elevators set IsState=@isstate,CollectionIsState=@isstate where Sign=@MACAddress
    else if (@isstate=2)
    update dbo.B_Elevators set IsState='1',CollectionIsState='0',CollectionCode=' ' where Sign=@MACAddress
    else
	update dbo.B_Elevators set IsState=@isstate,CollectionIsState=@isstate,CollectionCode=' ' where Sign=@MACAddress

两个变量是ado传进来的现在调用的次数十分频繁，大多数都是到30毫秒之间，但是经常出现几百毫秒甚至1秒往上的情况，这个时间我是在我VC程序里面截取的，我那边由于数据量很大，调用存储过程还是阻塞模式，需要一直等待结果(虽然不需要这个结果)，要求时间尽量短，所以想问一下为什么会出现这种情况[/quote]update是排他模式，一个会话在update，另外一个update的会话就必须等待，最终表现出来就是等

KevinLiu 2014-01-07

打赏
举报

另外查一下WAITTYPE，WAITRESOUCE之类的等待信息。

LongRui888 2014-01-07

打赏
举报

引用 9 楼 u011371217 的回复:

[quote=引用 4 楼 DBA_Huangzj 的回复:] 你这个情况应该就是锁问题导致的，我觉得改进设计才是王道，具体说说你的情况

引用 7 楼 OrchidCat 的回复:

400行的表，表扫描的速度就非常快。时间长短不一，这个是并发的问题。后面的要等待前面的事务完成。不用等待，就很快完成。需要等待就慢些，简单说就是排队。后面的要排比较久。

引用 6 楼 ap0405140 的回复:

400条数据的表,可不用建索引.

引用 3 楼 yupeigu 的回复:

确实有锁的问题。照理你的表才400条数据，应该不会更新一下，需要好几秒的

我现在是用vc中调用一个存储过程，存储过程中的代码是这样的


    if (@isstate=1)
    update dbo.B_Elevators set IsState=@isstate,CollectionIsState=@isstate where Sign=@MACAddress
    else if (@isstate=2)
    update dbo.B_Elevators set IsState='1',CollectionIsState='0',CollectionCode=' ' where Sign=@MACAddress
    else
	update dbo.B_Elevators set IsState=@isstate,CollectionIsState=@isstate,CollectionCode=' ' where Sign=@MACAddress

两个变量是ado传进来的现在调用的次数十分频繁，大多数都是到30毫秒之间，但是经常出现几百毫秒甚至1秒往上的情况，这个时间我是在我VC程序里面截取的，我那边由于数据量很大，调用存储过程还是阻塞模式，需要一直等待结果(虽然不需要这个结果)，要求时间尽量短，所以想问一下为什么会出现这种情况[/quote] 用这个查询一下，看看具体的阻塞情况：


select *
from sysprocesses
where blocked <> 0

D_Future 2014-01-07

打赏
举报

引用 4 楼 DBA_Huangzj 的回复:

你这个情况应该就是锁问题导致的，我觉得改进设计才是王道，具体说说你的情况

引用 7 楼 OrchidCat 的回复:

400行的表，表扫描的速度就非常快。时间长短不一，这个是并发的问题。后面的要等待前面的事务完成。不用等待，就很快完成。需要等待就慢些，简单说就是排队。后面的要排比较久。

引用 6 楼 ap0405140 的回复:

400条数据的表,可不用建索引.

引用 3 楼 yupeigu 的回复:

确实有锁的问题。照理你的表才400条数据，应该不会更新一下，需要好几秒的

我现在是用vc中调用一个存储过程，存储过程中的代码是这样的


    if (@isstate=1)
    update dbo.B_Elevators set IsState=@isstate,CollectionIsState=@isstate where Sign=@MACAddress
    else if (@isstate=2)
    update dbo.B_Elevators set IsState='1',CollectionIsState='0',CollectionCode=' ' where Sign=@MACAddress
    else
	update dbo.B_Elevators set IsState=@isstate,CollectionIsState=@isstate,CollectionCode=' ' where Sign=@MACAddress

两个变量是ado传进来的现在调用的次数十分频繁，大多数都是到30毫秒之间，但是经常出现几百毫秒甚至1秒往上的情况，这个时间我是在我VC程序里面截取的，我那边由于数据量很大，调用存储过程还是阻塞模式，需要一直等待结果(虽然不需要这个结果)，要求时间尽量短，所以想问一下为什么会出现这种情况

KevinLiu 2014-01-07