Transaction中SQL的顺序引起的死锁

因为项目的数据更新频率很高,导致经常出现死锁的问题。感觉以下遇到的一种情况比较典型,也比较tricky,计之。

问题描述:
如以下两条非常简单的SQL语句,它们共同组成了一个Transaction,那么在多线程高频率执行时就会引起死锁问题(当然这里要考虑锁的级别问题,一般多类似这种系统都会选择行锁,那么以下引起死锁的条件是两条语句都对同一行操作):

select <column1> from <table> where <column2> = ? 
update <table> set <column1> = %d where <column2> = '%s'

问题分析:
select语句需要“Shared Lock”,因而多个线程可以同时进入,而update需要“Exclusive Lock”,当两个线程同时执行了select语句,而获得了“Shared Lock”,而他们在接下来执行update语句时,都需要获得“Exclusive Lock”而产生竞争,导致死锁。

解决方案1:
互换他们的顺序,这样,在第一次执行update语句时,他们会竞争"Exclusive Lock"而引起没有得到“Exclusive Lock”的线程等待:

1, update <table> set <column2> = <column2> + <some value> where <column1> = '%s' 
2. select <column1> from <table> where <column2> = ? 
3. <column1> - <some value> to get the old <column1> value.

解决方案2:
采用“Hold Lock”方式,即在所有操作之前做一个dummy的update操作,这样可以保证在进Transaction之前需要先获得一个“Exclusive Lock”

时间: 2024-11-18 11:49:42

Transaction中SQL的顺序引起的死锁的相关文章

SQL Server 中的锁Range S-U,X-X 死锁以及事务

第一个部分代表了他锁定了一个索引范围,在这个范围内,所有索引使用 T 锁进行锁定: 第二个部分是而这个范围内已经命中的Key,这些 Key 将使用 K 锁进行锁定. 合并在一起我们说在这个范围内,索引范围和特定的row的锁定模式为 Range T-K. 举上一篇的一个例子吧: SELECT [data] FROM [MyTable] WHERE [index_column]>=20 AND [index_column]<=40 的锁的使用情况是: 实际上,上述语句产生的锁有两个部分,第一个是

SQL2008中SQL应用之- 死锁(Deadlocking)_mssql2008

在另一方释放资源前,会话1和会话2都不可能继续.所以,SQL Server会选择死锁中的一个会话作为"死锁牺牲品". 注意:死锁牺牲品的会话会被杀死,事务会被回滚. 注意:死锁与正常的阻塞是两个经常被混淆的概念. 发生死锁的一些原因: 1.应用程序以不同的次序访问表.例如会话1先更新了客户然后更新了订单,而会话2先更新了订单然后更新了客户.这就增加了死锁的可能性. 2.应用程序使用了长时间的事务,在一个事务中更新很多行或很多表.这样增加了行的"表面积",从而导致死锁

sqlserver2008-各位大神,请问sql的两个事务中的select如何能导致死锁

问题描述 各位大神,请问sql的两个事务中的select如何能导致死锁 捕获的trace日志非常大,我先放下出错的两条语句. sqlserver profiler捕获的是这样一条错误. 我想知道的是明明是两条select,S锁为何会导致死锁.而且死锁图形中的的排它锁是怎么回事,明明对keeping的这个资源没有update,只有delete,delete也会增加排它锁吗?行级的,还是表级的,为何我在prfiler中 捕获update或者delete时mode列没有提示锁? 问的有点多,请先看下图

Django中SQL查询

当 Django 中模型提供的查询 API 不能满足要求时,你可能需要使用原始的 sql 查询,这时候就需要用到 Manager.raw() 方法. Manager 类提供下面的一个方法,可以用于执行 sql: Manager.raw(raw_query, params=None, translations=None) 使用方法为: >>> for p in Person.objects.raw('SELECT * FROM myapp_person'): ... print(p) Jo

oracel中sql语句和pl/sql语句使用绑定变量

关于绑定变量的用法: 之前的文章介绍了绑定变量对于系统的重要性,这里对绑定变量的使用做进一步的分析和说明. 1)在sql语句中如何带入bind value SQL> variable x number; SQL> exec :x:=100; PL/SQL procedure successfully completed. SQL> select * from t where id=:x; no rows selected SQL> exec :x:=101; SQL> sel

sql执行顺序

原文:sql执行顺序SQL 不同于与其他编程语言的最明显特征是处理代码的顺序.在大数编程语言中,代码按编码顺序被处理,但是在SQL语言中,第一个被处理的子句是FROM子句,尽管SELECT语句第一个出现,但是几乎总是最后被处理.       每个步骤都会产生一个虚拟表,该虚拟表被用作下一个步骤的输入.这些虚拟表对调用者(客户端应用程序或者外部查询)不可用.只是最后一步生成的表才会返回 给调用者.如果没有在查询中指定某一子句,将跳过相应的步骤.下面是对应用于SQL server 2000和SQL

Oracle数据库中SQL语句的优化技巧_oracle

在SQL语句优化过程中,我们经常会用到hint,现总结一下在SQL优化过程中常见Oracle HINT的用法: 1. /*+ALL_ROWS*/ 表明对语句块选择基于开销的优化方法,并获得最佳吞吐量,使资源消耗最小化. 例如: SELECT /*+ALL+_ROWS*/ EMP_NO,EMP_NAM,DAT_IN FROM BSEMPMS WHERE EMP_NO='SCOTT'; 2. /*+FIRST_ROWS*/ 表明对语句块选择基于开销的优化方法,并获得最佳响应时间,使资源消耗最小化.

sql server 2000阻塞和死锁问题的查看与解决方法_MsSql

数据库发生阻塞和死锁的现象: 一.数据库阻塞的现象:第一个连接占有资源没有释放,而第二个连接需要获取这个资源.如果第一个连接没有提交或者回滚,第二个连接会一直等待下去,直到第一个连接释放该资源为止.对于阻塞,数据库无法处理,所以对数据库操作要及时地提交或者回滚.二.数据库死锁的现象:第一个连接占有资源没有释放,准备获取第二个连接所占用的资源,而第二个连接占有资源没有释放,准备获取第一个连接所占用的资源.这种互相占有对方需要获取的资源的现象叫做死锁.对于死锁,数据库处理方法:牺牲一个连接,保证另外

sql server 2000阻塞和死锁问题的查看与解决方法

数据库发生阻塞和死锁的现象: 一.数据库阻塞的现象:第一个连接占有资源没有释放,而第二个连接需要获取这个资源.如果第一个连接没有提交或者回滚,第二个连接会一直等待下去,直到第一个连接释放该资源为止.对于阻塞,数据库无法处理,所以对数据库操作要及时地提交或者回滚.二.数据库死锁的现象:第一个连接占有资源没有释放,准备获取第二个连接所占用的资源,而第二个连接占有资源没有释放,准备获取第一个连接所占用的资源.这种互相占有对方需要获取的资源的现象叫做死锁.对于死锁,数据库处理方法:牺牲一个连接,保证另外