关于死锁,很急,谢谢大家,在线等

Question

System.Web.HttpUnhandledException: 发生类型为 System.Web.HttpUnhandledException 的异常。 ---> System.Data.SqlClient.SqlException: 事务(进程 ID 123)与另一个进程被死锁在 线程 | 通信缓冲区 资源上，并且已被选作死锁牺牲品。请重新运行该事务。
System.Web.HttpUnhandledException: 发生类型为 System.Web.HttpUnhandledException 的异常。 ---> System.Data.SqlClient.SqlException: 事务(进程 ID 122)与另一个进程被死锁在 线程 | 通信缓冲区 资源上，并且已被选作死锁牺牲品。请重新运行该事务。
System.Web.HttpUnhandledException: 发生类型为 System.Web.HttpUnhandledException 的异常。 ---> System.Data.SqlClient.SqlException: 事务(进程 ID 109)与另一个进程被死锁在 线程 | 通信缓冲区 资源上，并且已被选作死锁牺牲。请重新运行该事务。
109的最先运行 122的是后面,以上3个错误 为不同用户操作
数据库是2005
是用.NET的WEB程序 查询统计报表的时候 发生此问题数据库查询语句用的是EXCE（@变量+@变量+@变量）实现
查询 也没用到事务
并且也设置了数据库隔离级别 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
查询最终的 也带了with (nolock)
FROM SaleInfo with (nolock)
    LEFT JOIN FH   ON FH.FMemo  = SaleInfo.FMemo and FH.FBigBookType    = SaleInfo.FBigBookType
LEFT JOIN WFH   ON WFH.FMemo  = SaleInfo.FMemo and WFH.FBigBookType    = SaleInfo.FBigBookType
LEFT JOIN TH   ON TH.FMemo  = SaleInfo.FMemo and TH.FBigBookType    = SaleInfo.FBigBookType
LEFT JOIN DZ   ON DZ.FMemo  = SaleInfo.FMemo and DZ.FBigBookType    = SaleInfo.FBigBookType
LEFT JOIN DisDZ  ON DisDZ.FMemo     = SaleInfo.FMemo and DisDZ.FBigBookType    = SaleInfo.FBigBookType
LEFT JOIN DisDZShiDianFh   ON DisDZShiDianFh.FMemo  = SaleInfo.FMemo and DisDZShiDianFh.FBigBookType    = SaleInfo.FBigBookType
LEFT JOIN DisDZShiDianTh   ON DisDZShiDianTh.FMemo  = SaleInfo.FMemo and DisDZShiDianTh.FBigBookType    = SaleInfo.FBigBookType LEFT JOIN DisDZTH  ON DisDZTH.FMemo     = SaleInfo.FMemo and DisDZTH.FBigBookType    = SaleInfo.FBigBookType
LEFT JOIN HK  ON HK.FMemo = SaleInfo.FMemo and HK.FBigBookType  = SaleInfo.FBigBookType
LEFT JOIN CS  ON CS.FMemo = SaleInfo.FMemo and CS.FBigBookType  = SaleInfo.FBigBookType
LEFT JOIN DisHK  ON DisHK.FMemo     = SaleInfo.FMemo and DisHK.FBigBookType    = SaleInfo.FBigBookType  
很急 哪位大大帮个忙

Answer 1

既然是死锁，那肯定不是这个查询单一引用。因为已经设定事务级别Uncommited有偿支持

Answer 2

也就是说 其他的 对应查询 也要加上 Uncommited？？？？？？

Answer 3

先不讲死锁问题,楼主设置了隔离等级为READ UNCOMMITTED,
本身会造成脏读,先确认一下这是业务需求所允许的吗?

Answer 4

如果允许的话,再来研究死锁的问题:
既然允许READ UNCOMMITTED,那么就简单了,
所有连线都用READ UNCOMMITTED,就不会产生死锁了.如果不允许脏读,那要从以下方面解决
 1.建索引加快查询速度,尽量避免查询时间交叉.
 2.是否LOCK_TIMEOUT设置过短,查询超时造成死锁.
 3.也可能是其他连线隔离级别不当造成LOCK.
 4.借助SQL Profiler分析死锁的具体原因.

Answer 5

这个没办法啊 同时用的人多 无所谓 了
其实 按里说 做报表 最好要等系统 无人 使用或关账了 才准确
但是 。。 所有的都要加 工作量太大了 而且 有的查询必须是可提交读谢谢 暂时将数据库服务器重启了下 就行了
使用  SQL Profiler 没看到 死锁进程啊

Answer 6

不知楼主是SQL Server什么版本.
做报表要避免产生大量锁定的话,
可参考SQL2008的数据库快照功能.

Answer 7

SQLSERVER 05  谢谢
05好像也有数据库快照吧 不过 一直没使用这个功能过
谢谢提醒 看下MSDN WEBCAST视频去

Answer 8

晕死 有个查询 用到了NOT IN 居然造成 这个错误 估计 这个引起的可能性很大
屏蔽了这个 就没了原来 是用 LEFT JOIN 关联 IS NULL 取代 NOT IN 写法
不过 LEFT JOIN 有点多 看起来复杂点 
后来 改成了 NOT IN 

Answer 9

不懂,能否把修改前后的完整SQL贴出来参考一下.

Answer 10

语句太多了 我也不懂 为什么一个查询 会引起这个问题 谢谢了
暂时屏蔽了那个子查询语句我原本 是用LEFT JOIN 关联的方式 替代 NOT IN
来提高查询性能
后来升级 为了维护方便 又改成了NOT IN 
谢谢 

Answer 11

楼主能不能贴出SQL语句的主要部分即可.
例如: select ... from ... not in / left join ...记得NOT IN的写法,对SQL执行性能不利.
至于是不是这样,还等高手来解答.

Answer 12

改成 LEFT JOIN 就没事了 主要关联 用到索引了
NOT IN 还是表扫描吧 用不到索引
查询数据在200多W条
数据出不来 
不知道 是否 能导致那个 错误