求助，关于update语句产生的死锁问题

where 条件有索引更新时间应该不会很长。
其他用户查询时可以用with (no lock)试试！

解决方案 »

  1.   

    表设计和索引设计编码等不合理的情况下，update会锁表，但是默认情况下是锁行的。单纯两个update不应该会死锁，顶多是阻塞，你应该还有其他非update的操作，比如中间还有select等
      

  2.   

    单纯的多个update除非别别的操作锁了表，单单更新操作不会变死锁吧，死锁是两个事务相互等待，但一个update除了要等之前操作完成不需要等待别的事务，理论上不会死锁哦
      

  3.   

    1、要看name上是否有索引，且实际执行计划是否是index seek
    2、遇到update和select相互阻塞，一般被牺牲的都是select。建议select增加nolock提高并发能力；
      

  4.   

    我的程序在异常提示里记录了函数的名称，出现异常的的那个函数确实只有我发的那一句操作。
    这个提示中说到的出现死锁并成为牺牲品，应该就是指的那个update语句吧。而且那张表在那个时间段确实没有什么其他操作的，是在凌晨执行的，那个时间点的前后几十秒时间有大量这样的异常报错。我觉得还是这个update操作，本身在大量执行时导致了上面说的问题。
      

  5.   

    会不会是update操作过多，导致sql server锁升级，锁住了整张表，最终引发其他update语句产生死锁呢？
      

  6.   

    使用SQL Profiler监控死锁，导出死锁XML文件，贴出来给大家看看。
      

  7.   

    同时是不是有别的进程在对这张表进行操作呢……光是UPDATE就出死锁真心不能理解了= -