我在内联表中有一个恒定的'select ... for update'查询。
主要条件是它选择'column1'所在的所有字段<超过100。
在后台有持续的插入,这可能涉及'column1'是<超过100,但这不是问题。如果第一次选择更新错过了它,因为它正在执行该查询时,或者正在获取结果数组时,下一个将捕获它,我很乐意将第一个查询标记为缺少它,因为它是'太晚了。
如果我有10个'select for update'查询等待,因为inndob字段锁定,我应该自己处理它们的排队还是让数据库对它进行排序?我认为处理这个问题的正确方法是自己排队查询?
所以当脚本到达
时$sql = "SELECT * FROM ... FOR UDPATE"
事先检查队列数组(?),如果队列数组不为空,则将此脚本调用放在最后的队列数组中,然后每隔几毫秒检查一次队列数组,直到它到达队列中的数字1? / p>
我在这里思考的是正确的思路......重要的是我现在应该做到这一点,而不是稍后再回来
编辑:我可以添加任何内容来增加回复的可能性:)
答案 0 :(得分:3)
InnoDB应该为您处理排队。如果有关于相关行的锁的事务正在进行中,那么第二个事务试图用另一个SELECT FOR UPDATE语句获取相同的锁,那么第二个语句将等到第一个事务提交。
您可以自己测试一下:
START TRANSACTION
。 SELECT ... FOR UPDATE
。 在第一个窗口中,运行SHOW ENGINE INNODB STATUS
并观察事务及其锁定。您应该看到输出包含以下内容:
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 3B17, ACTIVE 4 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 2, OS thread handle 0x7ff27ae2d700, query id 28 192.168.56.1 root Sending data
select * from foo where id < 100 for update
------- TRX HAS BEEN WAITING 4 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 266 page no 3 n bits 72 index `PRIMARY` of table `test`.`foo` trx id 3B17 lock_mode X waiting
------------------
TABLE LOCK table `test`.`foo` trx id 3B17 lock mode IX
RECORD LOCKS space id 266 page no 3 n bits 72 index `PRIMARY` of table `test`.`foo` trx id 3B17 lock_mode X waiting
---TRANSACTION 3B16, ACTIVE 70 sec
2 lock struct(s), heap size 376, 2 row lock(s)
MySQL thread id 1, OS thread handle 0x7ff27ae6e700, query id 29 192.168.56.1 root
show engine innodb status
TABLE LOCK table `test`.`foo` trx id 3B16 lock mode IX
RECORD LOCKS space id 266 page no 3 n bits 72 index `PRIMARY` of table `test`.`foo` trx id 3B16 lock_mode X
请注意,在上面,事务3B16持有锁,事务3B17正在等待锁。
事务3B16显示它当前正在运行“show engine innodb status”,但它仍保留在之前的SELECT ... FOR UPDATE中获取的锁。即使该语句已完成,事务也不会,并且在事务结束时会释放锁。
如果事务3B17等待的时间超过lock_wait_timeout
秒,并且第一个事务仍未提交或回滚,则等待语句放弃并产生此错误:
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction