sqlserver 关于事物的问题讨论

--- 参与讨论,说得不一定对啊 ---

我觉得你有必要澄清一下具体情况.
(1) "... 卡在那边，必须等待事务结束后才能执行..." 和
(2) "... 还是会报错 事务死锁..."  是两个完全不同的概念.

(1) 举例
假定事物Ａ持续 60秒
Beging Transaction Ａ
 Update Student
 Set    Student_Last_Name = 'Lee'
 ...
 ...
 ..
Commit Transaction Ａ  --                          

当事物Ａ没有提交时，下面类似的查询只有等待 - 甚至有可能等上60秒
Select Student_Last_Name
From   Student
这个等待的过程是正常的现象．原因是SQL Server在事物Ａ从开始执行到提交之前并不能肯定学生们的姓是张王李赵还是Lee.

针对你的问题"...有什么办法能够使得其他地方可以顺利提取数据的 ...", 答案应该是没有，原因如上．不过话又说回来，如果你能容忍结果的不确定性，不想等待, 可以执行类似下面的语句．也就是你所说的"...降低...隔离级别..."

Select Student_Last_Name
From   Student WITH (NOLOCK)

(2) 死锁说的是事物Ａ等待事物Ｂ正在锁定的资源，同时事物Ｂ又等待事物Ａ正在锁定的资源．换句话说无论等待多长时间，也不能A和B都完成.  设计程序可以尽可能减少死锁的情况,但不能完全排除. SQL Server有自动探测死锁的功能. 出现死锁后,SQL Server选择牺牲一事物, 如A, 使得事物B得以完成.

针对你的问题在于"...实际程序开发过程中 还是会报错 事务死锁 ..." 也许你可以考虑A和B尽可能少锁定对方的资源? 程序设计考虑出现死锁的情况后,如何应对?

Transaction (Process ID 57) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

这个是错误代码。。明细是死锁咯。

确定是死锁问题后,通常可以做两个方面的工作.

首先因为无法完全避免,程序设计需要考虑到如何处理死锁. 涉及到事物时可以使用 Try and Catch. 大体思路是先试着操作. 能通过则提交, 否则就回滚,等待,再试.

推荐你读下  http://msdn.(v=sql.80).aspx

其次 - 当然也是工作难点 - 针对参与死锁的事物,着重研究是否一定要用事物,可否一个事物变两个小事物,事物内有无不必要的内容,对表的操作能否顺序一致, 表的索引等等等等 (包括你提到的降低级别).

针对你的问题,既然只是偶尔产生死锁,也许你只需要做第一方面的工作?