--- 参与讨论,说得不一定对啊 ---
我觉得你有必要澄清一下具体情况.
(1) "... 卡在那边,必须等待事务结束后才能执行..." 和
(2) "... 还是会报错 事务死锁..."
是两个完全不同的概念.
(1) 举例
假定事物A持续 60秒
Beging Transaction A
Update Student
Set
Student_Last_Name = 'Lee'
...
...
..
Commit Transaction A
--
当事物A没有提交时,下面类似的查询只有等待 - 甚至有可能等上60秒
Select Student_Last_Name
From
Student
这个等待的过程是正常的现象.原因是SQL Server在事物A从开始执行到提交之前并不能肯定学生们的姓是张王李赵还是Lee.
针对你的问题"...有什么办法能够使得其他地方可以顺利提取数据的 ...", 答案应该是没有,原因如上.不过话又说回来,如果你能容忍结果的不确定性,不想等待, 可以执行类似下面的语句.也就是你所说的"...降低...隔离级别..."
Select Student_Last_Name
From
Student WITH (NOLOCK)
(2) 死锁说的是事物A等待事物B正在锁定的资源,同时事物B又等待事物A正在锁定的资源.换句话说无论等待多长时间,也不能A和B都完成.
设计程序可以尽可能减少死锁的情况,但不能完全排除. SQL Server有自动探测死锁的功能. 出现死锁后,SQL Server选择牺牲一事物, 如A, 使得事物B得以完成.
针对你的问题在于"...实际程序开发过程中 还是会报错 事务死锁 ..." 也许你可以考虑A和B尽可能少锁定对方的资源? 程序设计考虑出现死锁的情况后,如何应对?