分析事务与锁（五）

分析事务与锁（五）

---在第三个连接中执行以下语句，由于不在同一个事务之内，所以会被锁定

update WBK_OPINION set OPINION_VALUE='true'

where OPINION_ID='PreEntryIDUse' 

 

 

rollback tran  ---回滚

 

         1. 你可以根据以上代码，自行编码相应的测试示例，通过Management studio分别使用三条连接来执行更新示例代码，你会发现享有相同TOKEN的两条连接会一同更新，而其获取的@@TRANCOUNT系统变量也是一样的。而不在同一事务中的其他连接则会被锁住。@@TRANCOUNT也与前述的事务无关。

        2.提交不同的数据访问路径。如果两条不同连接的SQL语句，因为抢相同索引而导致死锁，可以考虑为不同的访问语句建立不同的索引，通过索引提示强制让两条连接访问各自的索引。或者是两条不同的连接访问相同的数据表，如果引用不同的索引，但各自的访问顺序正彼此交错，形成死锁，则可强制两条连接使用相同的索引，以维护访问先后秩序。

      不管如何，采用此类解决方式时，都要考虑额外的性能损耗，因为你通过索引提示强制了索引访问，让查询优化程序不能凭借数据的特性使用最佳的索引。

 

五、发生死锁后的处理

       通过设置SET DEADLOCK_PRIORITY LOW，让不重要的事务自动放弃，并在这些连接执行的业务逻辑中，加上针对死锁的错误处理。

      事实上，在非常复杂的高并发量的系统中，要完全预防死锁，或者要知道什么样的用户在特殊的访问次序中会发生死锁，是非常困难的。所以应用程序应该对死锁错误“1205”要有相应的处理，以完成原有的业务逻辑的处理或是善后清除处理。

 

 

 

 

 

 

 

 

 

分类: 数据库