[用事实说明两个凡是]一个由mysql事务隔离级别造成的问题分析

原创
2015/11/24 12:52
阅读数 7.9K

背景

最近要做一个批跑服务, 基本逻辑就是定时扫描数据库的记录, 有满足条件的就进行处理(一条记录代表一个任务,以下任务与记录含义相同). 要求支持多机部署批跑服务.

批跑支持多机部署实现方案

要实现多机部署, 只要保证每个批跑服务实例每次只获取一条记录, 处理完再获取下一条即可. 其中最种要的是避免不同的实例获取到同一条记录,即所谓抢任务.

先看表结构设计:

create database if not exists ae;
create table ae.task (
id int primary key,
status int);
-- status为0说明任务可处理,其它不可处理

以上是简化的表结构,但足以说明本文试图说明的问题.

要避免抢任务, oracle的做法, 直接

update ae.task set status=1 where status=0 and rownum = 1 returning id

即可.

mysql的要啰嗦一点:

select id from ae.task where status=0; -- 得到ID
update ae.task where id = ${id} and status=0;

这两个sql,第一个sql用于获取符合条件的任务, 第二个sql用户将任务锁定. 在并发的场景下, 有可能不同的批跑实例的第一个SQL会返回相同的记录, 但第二个sql只有一个会更新成功, 通过判断affected rows即可知道哪个锁定成功. 锁定成功的继续处理本任务, 锁定失败的继续处理其它任务.

问题现象

管理后台提交了一个任务后, 两个批跑实例恰好同时启动, 进入抢任务环节. 结果发现异常, 其中一个实例成功抢到任务, 但另一个实例则挂死了:

抢到任务的实例:

2015-11-23 19:42:01|INFO|exec_task.php|40||get one task: 11
...
2015-11-23 19:42:01|INFO|exec_task.php|107||line_count: 9
2015-11-23 19:42:01|INFO|exec_task.php|147||fork child success: 8346
2015-11-23 19:42:01|INFO|exec_task.php|264||[0] pid: 8346, start: 0, stop: 0

2015-11-23 19:42:01|INFO|exec_task.php|147||fork child success: 8347
2015-11-23 19:42:01|INFO|exec_task.php|264||[1] pid: 8347, start: 1, stop: 1

2015-11-23 19:42:01|INFO|exec_task.php|147||fork child success: 8348
2015-11-23 19:42:01|INFO|exec_task.php|264||[2] pid: 8348, start: 2, stop: 2

2015-11-23 19:42:01|INFO|exec_task.php|147||fork child success: 8349
...

没有抢到任务的实例:

2015-11-23 19:42:01|INFO|function.inc.php|100||task_id 11 is locked by another process, get next task
2015-11-23 19:42:01|INFO|function.inc.php|100||task_id 11 is locked by another process, get next task
2015-11-23 19:42:01|INFO|function.inc.php|100||task_id 11 is locked by another process, get next task
2015-11-23 19:42:01|INFO|function.inc.php|100||task_id 11 is locked by another process, get next task
2015-11-23 19:42:01|INFO|function.inc.php|100||task_id 11 is locked by another process, get next task
2015-11-23 19:42:01|INFO|function.inc.php|100||task_id 11 is locked by another process, get next task
2015-11-23 19:42:01|INFO|function.inc.php|100||task_id 11 is locked by another process, get next task
2015-11-23 19:42:01|INFO|function.inc.php|100||task_id 11 is locked by another process, get next task
2015-11-23 19:42:01|INFO|function.inc.php|100||task_id 11 is locked by another process, get next task

可以看到没有抢到任务的实例进入了死循环.

原因分析

按照我们之前的设计, 如果第二条SQL锁定任务的时候失败了, 获取下一个任务. 应当不会死循环. 死循环的原因是因为没有抢到任务的实例, 在执行第一个SQL的时候, 一直返回了相同的记录(id=11,实际上当时也只有一条记录)

请注意, 抢到任务的实例抢到任务后, 会把状态更新并提交, 按说抢不到任务的实例会看到此状态更新,并导致第一条sql查不到数据,然后 正常退出.

而事实上抢不到任务的实例看不到此变化, 说明事务隔离级别(Transaction Isolation Level)不是"READ COMMITED", 而是其它. 经确认, 级别是"REPEATABLE-READ"

mysql> select @@TX_ISOLATION;
+-----------------+
| @@TX_ISOLATION  |
+-----------------+
| REPEATABLE-READ |

"REPEATABLE-READ" 看到的数据是事务启动时的样子,所以看不到抢到任务的实例对任务状态的修改. 进而导致死循环.

请注意执行第一个SQL查询满足条件的任务是在一个事务内进行的. 此事务实际上是业务的需要, 除了获取到任务,还需要获取其它资源,如果获取不到其它 资源, 则rollback任务,以便下次处理.

ORACLE相应的事务隔离级别是"Serializable Isolation Level", 如上描述的这个场景, 在ORACLE下的反应是抢不到任务的实例在试图更新任务状态的 时候,会返回一个"ORA-08177: Cannot serialize access for this transaction"错误, 程序也可以正常退出. 详见<<Oracle Database Concepts 11g Release 2 (11.2) E40540-04>> 第9章"Overview of Oracle Database Transaction Isolation Levels"

mysql在"REPEATABLE-READ"的事务隔离级别上的表现是不能让人满意的. 查询到的数据是事务启动时的样子,但更新的时候看到的数据又是其它事务提交 后的结果,并且update也没有错误提示.

而"SERIALIZABLE"更糟糕, 如果同时开了两个session, 干脆直接锁表了, 谁了更新不了. 这就势必造成另一个问题, 既然大家都更新不了,那就rollback事务, 重试呗. 但是重试也是很有可能大家再同时开了事务,又锁死了, 一直死循环. 为了解决这种情况,可能的做法是, 各自等待一个随机时间再重试,让随机打破这个僵局. 不知道是否有其它办法,欢迎指教.

解决方法

  1. 修改session的事务隔离级别
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
  1. 不断查询满足条件的任务不要放到一个事务里. 发现"affected rows"为0,更新不到数据时, 事务rollback,重新启动事务. 即在循环里不断开启事务而不是在事务里不断循环.

  2. 还有一个办法是开事务然后select for update, 但是这种方法会导致锁表, 必须等待其它事务提交后才能返回. 当初我进行设计的时候,是计划使用select for update的方式的, 但是最终没有使用, 现在回想, 可能是没有开事务, 结果两个实例都查询到了相同的记录, 所以被我否定了. 但是看我另一个文章 <<mysql抢单>>又似乎可能是由于锁表而弃用了, 原因已经不可考了.

但从本个需求来说, 似乎使用select for update来让把表锁住会更简单.

另一个问题

你以为抢到任务的实例就可以高枕无忧了吗, 错了! 等他高高兴兴处理完任务, 要把任务状态置为成功时, 发现这个任务居然被没有抢到任务的实例给锁了, 自已只能得到一个锁超时的错误

2015-11-23 19:42:52|ERR|function.inc.php|113||SQL fail: Lock wait timeout exceeded; try restarting transaction

请期待下一个问题分析.

补充说明

今天回来确认了一下, 实际上ORACEL的update task set status = 1 where status = 0 and rownum = 1 returning taskid 这个SQL也会把表锁住.

所以可以用@flygogo 在30楼提出的方法模拟oracle 的returning

SET @update_id := 0; 
update ae.task set status=1, id = (SELECT @update_id := id) where status=0 limit 1; SELECT @update_id;

oracle

而postgresql的update似乎没有limit 1之类的限定只更新一条的写法?

同时ORACLE和postgresql的select for update 也都会锁表.

所以就本文所讨论的范围来说, 似乎不能说是两个凡是. 叉!

再补充说明

差点被绕晕了. 其实本文所指出的mysql在"REPEATABLE-READ"事务隔离级别下的表现是奇怪的,不直观的,这点值得注意. 明明select出来的数据是可更新, 而更新时候又没有成功, 会让人非常疑惑. 而为oracel在"Serializable"级别下发现数据已经被更新了之后,抛出"ORA-08177"的做法才更直观更合适.

本文另一个意义是分享了一种不锁表实现队列的方法

展开阅读全文
打赏
4
109 收藏
分享
加载中

引用来自“周翼翼”的评论

引用来自“zhxh007”的评论

如果多个字段呢,比如叫hostname
update ae.task set status=1,hostname="传入执行这条sql的ip或者其它能标识这个进程的" where status= 0 limit 500;
然后程序程序查询的时候select * from ae.task where hostname="传入执行这条sql的ip或者其它能标识这个进程的" and status=1
这样查询到自己机器更新的数据,不知道可以不可以!

这样就是不管能不能处理,都先揽过来,就不是分布式了。每次只揽一条才是最合适的。
嗯!这样做可能性能不好,不过一次更新多点儿的话,也还好,实际上sql还有一层,先把要处理的敛过来,同时打上时间戳,别的机器抢的时候,会看之前机器的处理情况,比如发现之前的机器隔了指定的时间,还没处理完,就认为那台机器挂了,就直接抢过来自己处理,处理完后根据id删掉处理的任务,处理失败的就就把本条记录写到别的表,同时删掉,然后由其它进程处理这张失败的表!做重试,之前的系统就是这么搞的!不知道跟你这个像不像
2015/11/27 13:04
回复
举报

引用来自“逝水fox”的评论

后续更新同个数据的语句与前面查询结果有关,需要select ... for update; 不需要改事务隔离级别。原因在于MySQL InnoDB在REPEATABLE-READ下select默认是用的非锁定一致性读,不加锁,读的undo段的数据拷贝...SERIALIZABLE下默认只是读锁一样有问题。

引用来自“周翼翼”的评论

select for update 会锁表, 这是我不希望看到的. 但确实这个需求让他锁表会更简单.
select for update 会锁表? 锁行也可
2015/11/27 08:45
回复
举报
细节是魔鬼。mysql对于各种功能都支持,等你用的时候就明白啥是要你命3000了。当然当作超级记事本用用还是不错的。
2015/11/26 13:18
回复
举报
周翼翼博主

引用来自“宏哥”的评论

引用来自“周翼翼”的评论

引用来自“flygogo”的评论

引用来自“flygogo”的评论

看了一下 ,看到主要说道了两个问题:
1. REPEATABLE-READ 下一直死循环:
这个产生的原因我估计是因为这个事务一直没有结束,应该考虑放到调用事务方法的最外层做循环,一个事务失败了,就再启动一个,可以避免很长的事务,引起更多的问题。

2. 关于 分布式的锁问题, REPEATABLE-READ 和 READ COMMITED 都无法解决此问题,因为你使用的 select id from ae.task where status=0; -- 得到ID 这一步是快照读,无法做到严格意义的两个方面都取出同样的。 而你第二次通过乐观锁的方法 update ae.task set status=1 where id = ${id} and status=0;(此处是主干读) 可以解决此冲突,而你是不是觉得两步可能浪费了?

而使用oracle update ae.task set status=1 where status=0 and rownum = 1 returning id 这种方法是非快照读当然可以解决。

select for update会导致锁表 这个如果是innodb在加上其他索引条件的情况下,本身是不会的,可能是你表数据量本来就少,比如说你所说的只有一条。

另外顺便提一句,简单从这个场景来看 select lock in shared mode 应该是比较适合的,即可以阻止update操作,又不至于读到的是快照数据。

引用来自“周翼翼”的评论

lock in share mode解决不了问题. 多个进程很可能获取到相同的id, 必须要要根据update的结果来判断谁获取到的任务. 同时两个进程同时lock in share mode之后, 谁也update不了,除非两个进程恰好同时update然后引发dead lock,其中一个才会成功. 事情变复杂了,但还是没有解决问题.
lock in share mode的确产生类似的问题,原理和你说的 使用SERIALIZABLE级别产生的问题是一样的。 还是从你的需求出发来看的话,就是觉得oracle提供了返回id的方式很直接。 其实 mysql 也是可以通过类似的方法搞定的: SET @update_id := 0; update ae.task set status=1, id = (SELECT @update_id := id) where status=0 limit 1; SELECT @update_id;

这样还是会锁表。

引用来自“flygogo”的评论

如果你说这样锁表了的话,那么我觉得 同样的结构 同样的数据量,oracle 应该也是锁表的。 就如你说 你只有一条数据,锁升级引起的锁表

引用来自“周翼翼”的评论

我的意思是, 表里有多条满足条件的记录, 你上面说的方法会锁表(虽然limite 1), 而oracle同样的情况只会锁update的那一条

引用来自“宏哥”的评论

postgresql 也只会锁一条 所以, 用postgresql Pl/sql直接实现一个物化队列很简单。

引用来自“周翼翼”的评论

晚上回来重新试了一下, update task set status = 1 where status = 0 and rownum = 1 ORACLE 也是会锁表
update xxx set yyy where id in( select xxxx from table where rownum=1 for update)

有for update 似乎语法错误。没有for update 还是会锁表。我估计是没有主键update导致的锁表。rownum = 1只是对满足where条件的结果集的过滤,而锁表应当发生在返回结果集前。这只是猜测,明天再查查资料。
2015/11/26 00:12
回复
举报

引用来自“周翼翼”的评论

引用来自“flygogo”的评论

引用来自“flygogo”的评论

看了一下 ,看到主要说道了两个问题:
1. REPEATABLE-READ 下一直死循环:
这个产生的原因我估计是因为这个事务一直没有结束,应该考虑放到调用事务方法的最外层做循环,一个事务失败了,就再启动一个,可以避免很长的事务,引起更多的问题。

2. 关于 分布式的锁问题, REPEATABLE-READ 和 READ COMMITED 都无法解决此问题,因为你使用的 select id from ae.task where status=0; -- 得到ID 这一步是快照读,无法做到严格意义的两个方面都取出同样的。 而你第二次通过乐观锁的方法 update ae.task set status=1 where id = ${id} and status=0;(此处是主干读) 可以解决此冲突,而你是不是觉得两步可能浪费了?

而使用oracle update ae.task set status=1 where status=0 and rownum = 1 returning id 这种方法是非快照读当然可以解决。

select for update会导致锁表 这个如果是innodb在加上其他索引条件的情况下,本身是不会的,可能是你表数据量本来就少,比如说你所说的只有一条。

另外顺便提一句,简单从这个场景来看 select lock in shared mode 应该是比较适合的,即可以阻止update操作,又不至于读到的是快照数据。

引用来自“周翼翼”的评论

lock in share mode解决不了问题. 多个进程很可能获取到相同的id, 必须要要根据update的结果来判断谁获取到的任务. 同时两个进程同时lock in share mode之后, 谁也update不了,除非两个进程恰好同时update然后引发dead lock,其中一个才会成功. 事情变复杂了,但还是没有解决问题.
lock in share mode的确产生类似的问题,原理和你说的 使用SERIALIZABLE级别产生的问题是一样的。 还是从你的需求出发来看的话,就是觉得oracle提供了返回id的方式很直接。 其实 mysql 也是可以通过类似的方法搞定的: SET @update_id := 0; update ae.task set status=1, id = (SELECT @update_id := id) where status=0 limit 1; SELECT @update_id;

这样还是会锁表。

引用来自“flygogo”的评论

如果你说这样锁表了的话,那么我觉得 同样的结构 同样的数据量,oracle 应该也是锁表的。 就如你说 你只有一条数据,锁升级引起的锁表

引用来自“周翼翼”的评论

我的意思是, 表里有多条满足条件的记录, 你上面说的方法会锁表(虽然limite 1), 而oracle同样的情况只会锁update的那一条

引用来自“宏哥”的评论

postgresql 也只会锁一条 所以, 用postgresql Pl/sql直接实现一个物化队列很简单。

引用来自“周翼翼”的评论

晚上回来重新试了一下, update task set status = 1 where status = 0 and rownum = 1 ORACLE 也是会锁表
update xxx set yyy where id in( select xxxx from table where rownum=1 for update)
2015/11/25 23:45
回复
举报
周翼翼博主

引用来自“周翼翼”的评论

引用来自“flygogo”的评论

引用来自“flygogo”的评论

看了一下 ,看到主要说道了两个问题:
1. REPEATABLE-READ 下一直死循环:
这个产生的原因我估计是因为这个事务一直没有结束,应该考虑放到调用事务方法的最外层做循环,一个事务失败了,就再启动一个,可以避免很长的事务,引起更多的问题。

2. 关于 分布式的锁问题, REPEATABLE-READ 和 READ COMMITED 都无法解决此问题,因为你使用的 select id from ae.task where status=0; -- 得到ID 这一步是快照读,无法做到严格意义的两个方面都取出同样的。 而你第二次通过乐观锁的方法 update ae.task set status=1 where id = ${id} and status=0;(此处是主干读) 可以解决此冲突,而你是不是觉得两步可能浪费了?

而使用oracle update ae.task set status=1 where status=0 and rownum = 1 returning id 这种方法是非快照读当然可以解决。

select for update会导致锁表 这个如果是innodb在加上其他索引条件的情况下,本身是不会的,可能是你表数据量本来就少,比如说你所说的只有一条。

另外顺便提一句,简单从这个场景来看 select lock in shared mode 应该是比较适合的,即可以阻止update操作,又不至于读到的是快照数据。

引用来自“周翼翼”的评论

lock in share mode解决不了问题. 多个进程很可能获取到相同的id, 必须要要根据update的结果来判断谁获取到的任务. 同时两个进程同时lock in share mode之后, 谁也update不了,除非两个进程恰好同时update然后引发dead lock,其中一个才会成功. 事情变复杂了,但还是没有解决问题.
lock in share mode的确产生类似的问题,原理和你说的 使用SERIALIZABLE级别产生的问题是一样的。 还是从你的需求出发来看的话,就是觉得oracle提供了返回id的方式很直接。 其实 mysql 也是可以通过类似的方法搞定的: SET @update_id := 0; update ae.task set status=1, id = (SELECT @update_id := id) where status=0 limit 1; SELECT @update_id;

这样还是会锁表。

引用来自“flygogo”的评论

如果你说这样锁表了的话,那么我觉得 同样的结构 同样的数据量,oracle 应该也是锁表的。 就如你说 你只有一条数据,锁升级引起的锁表

引用来自“周翼翼”的评论

我的意思是, 表里有多条满足条件的记录, 你上面说的方法会锁表(虽然limite 1), 而oracle同样的情况只会锁update的那一条

引用来自“宏哥”的评论

postgresql 也只会锁一条 所以, 用postgresql Pl/sql直接实现一个物化队列很简单。
晚上回来重新试了一下, update task set status = 1 where status = 0 and rownum = 1 ORACLE 也是会锁表
2015/11/25 22:57
回复
举报
我觉得还是用消息服务器进行分发比较好,把符合条件的数据查出来放到消息队列里面,多跑几个消费者效果是一样的,并且不会出现上面的问题
2015/11/25 22:43
回复
举报

引用来自“周翼翼”的评论

引用来自“flygogo”的评论

引用来自“flygogo”的评论

看了一下 ,看到主要说道了两个问题:
1. REPEATABLE-READ 下一直死循环:
这个产生的原因我估计是因为这个事务一直没有结束,应该考虑放到调用事务方法的最外层做循环,一个事务失败了,就再启动一个,可以避免很长的事务,引起更多的问题。

2. 关于 分布式的锁问题, REPEATABLE-READ 和 READ COMMITED 都无法解决此问题,因为你使用的 select id from ae.task where status=0; -- 得到ID 这一步是快照读,无法做到严格意义的两个方面都取出同样的。 而你第二次通过乐观锁的方法 update ae.task set status=1 where id = ${id} and status=0;(此处是主干读) 可以解决此冲突,而你是不是觉得两步可能浪费了?

而使用oracle update ae.task set status=1 where status=0 and rownum = 1 returning id 这种方法是非快照读当然可以解决。

select for update会导致锁表 这个如果是innodb在加上其他索引条件的情况下,本身是不会的,可能是你表数据量本来就少,比如说你所说的只有一条。

另外顺便提一句,简单从这个场景来看 select lock in shared mode 应该是比较适合的,即可以阻止update操作,又不至于读到的是快照数据。

引用来自“周翼翼”的评论

lock in share mode解决不了问题. 多个进程很可能获取到相同的id, 必须要要根据update的结果来判断谁获取到的任务. 同时两个进程同时lock in share mode之后, 谁也update不了,除非两个进程恰好同时update然后引发dead lock,其中一个才会成功. 事情变复杂了,但还是没有解决问题.
lock in share mode的确产生类似的问题,原理和你说的 使用SERIALIZABLE级别产生的问题是一样的。 还是从你的需求出发来看的话,就是觉得oracle提供了返回id的方式很直接。 其实 mysql 也是可以通过类似的方法搞定的: SET @update_id := 0; update ae.task set status=1, id = (SELECT @update_id := id) where status=0 limit 1; SELECT @update_id;

这样还是会锁表。

引用来自“flygogo”的评论

如果你说这样锁表了的话,那么我觉得 同样的结构 同样的数据量,oracle 应该也是锁表的。 就如你说 你只有一条数据,锁升级引起的锁表

引用来自“周翼翼”的评论

我的意思是, 表里有多条满足条件的记录, 你上面说的方法会锁表(虽然limite 1), 而oracle同样的情况只会锁update的那一条
postgresql 也只会锁一条 所以, 用postgresql Pl/sql直接实现一个物化队列很简单。
2015/11/25 20:28
回复
举报
周翼翼博主

引用来自“周翼翼”的评论

引用来自“flygogo”的评论

引用来自“flygogo”的评论

看了一下 ,看到主要说道了两个问题:
1. REPEATABLE-READ 下一直死循环:
这个产生的原因我估计是因为这个事务一直没有结束,应该考虑放到调用事务方法的最外层做循环,一个事务失败了,就再启动一个,可以避免很长的事务,引起更多的问题。

2. 关于 分布式的锁问题, REPEATABLE-READ 和 READ COMMITED 都无法解决此问题,因为你使用的 select id from ae.task where status=0; -- 得到ID 这一步是快照读,无法做到严格意义的两个方面都取出同样的。 而你第二次通过乐观锁的方法 update ae.task set status=1 where id = ${id} and status=0;(此处是主干读) 可以解决此冲突,而你是不是觉得两步可能浪费了?

而使用oracle update ae.task set status=1 where status=0 and rownum = 1 returning id 这种方法是非快照读当然可以解决。

select for update会导致锁表 这个如果是innodb在加上其他索引条件的情况下,本身是不会的,可能是你表数据量本来就少,比如说你所说的只有一条。

另外顺便提一句,简单从这个场景来看 select lock in shared mode 应该是比较适合的,即可以阻止update操作,又不至于读到的是快照数据。

引用来自“周翼翼”的评论

lock in share mode解决不了问题. 多个进程很可能获取到相同的id, 必须要要根据update的结果来判断谁获取到的任务. 同时两个进程同时lock in share mode之后, 谁也update不了,除非两个进程恰好同时update然后引发dead lock,其中一个才会成功. 事情变复杂了,但还是没有解决问题.
lock in share mode的确产生类似的问题,原理和你说的 使用SERIALIZABLE级别产生的问题是一样的。 还是从你的需求出发来看的话,就是觉得oracle提供了返回id的方式很直接。 其实 mysql 也是可以通过类似的方法搞定的: SET @update_id := 0; update ae.task set status=1, id = (SELECT @update_id := id) where status=0 limit 1; SELECT @update_id;

这样还是会锁表。

引用来自“flygogo”的评论

如果你说这样锁表了的话,那么我觉得 同样的结构 同样的数据量,oracle 应该也是锁表的。 就如你说 你只有一条数据,锁升级引起的锁表
我的意思是, 表里有多条满足条件的记录, 你上面说的方法会锁表(虽然limite 1), 而oracle同样的情况只会锁update的那一条
2015/11/25 19:30
回复
举报

引用来自“周翼翼”的评论

引用来自“flygogo”的评论

引用来自“flygogo”的评论

看了一下 ,看到主要说道了两个问题:
1. REPEATABLE-READ 下一直死循环:
这个产生的原因我估计是因为这个事务一直没有结束,应该考虑放到调用事务方法的最外层做循环,一个事务失败了,就再启动一个,可以避免很长的事务,引起更多的问题。

2. 关于 分布式的锁问题, REPEATABLE-READ 和 READ COMMITED 都无法解决此问题,因为你使用的 select id from ae.task where status=0; -- 得到ID 这一步是快照读,无法做到严格意义的两个方面都取出同样的。 而你第二次通过乐观锁的方法 update ae.task set status=1 where id = ${id} and status=0;(此处是主干读) 可以解决此冲突,而你是不是觉得两步可能浪费了?

而使用oracle update ae.task set status=1 where status=0 and rownum = 1 returning id 这种方法是非快照读当然可以解决。

select for update会导致锁表 这个如果是innodb在加上其他索引条件的情况下,本身是不会的,可能是你表数据量本来就少,比如说你所说的只有一条。

另外顺便提一句,简单从这个场景来看 select lock in shared mode 应该是比较适合的,即可以阻止update操作,又不至于读到的是快照数据。

引用来自“周翼翼”的评论

lock in share mode解决不了问题. 多个进程很可能获取到相同的id, 必须要要根据update的结果来判断谁获取到的任务. 同时两个进程同时lock in share mode之后, 谁也update不了,除非两个进程恰好同时update然后引发dead lock,其中一个才会成功. 事情变复杂了,但还是没有解决问题.
lock in share mode的确产生类似的问题,原理和你说的 使用SERIALIZABLE级别产生的问题是一样的。 还是从你的需求出发来看的话,就是觉得oracle提供了返回id的方式很直接。 其实 mysql 也是可以通过类似的方法搞定的: SET @update_id := 0; update ae.task set status=1, id = (SELECT @update_id := id) where status=0 limit 1; SELECT @update_id;

这样还是会锁表。
如果你说这样锁表了的话,那么我觉得 同样的结构 同样的数据量,oracle 应该也是锁表的。 就如你说 你只有一条数据,锁升级引起的锁表
2015/11/25 19:26
回复
举报
更多评论
打赏
44 评论
109 收藏
4
分享
在线直播报名
返回顶部
顶部