我在inndob表中有一个恒定的’select … for update’查询流.
主要条件是它选择’column1’所在的所有字段
在后台有持续插入,这可能涉及’column1’是
如果我有10个’select for update’查询等待,因为inndob字段锁定,我应该自己处理它们的排队还是让数据库对它进行排序?我认为处理这个问题的正确方法是自己排队查询?
所以当脚本到达时
$sql = "SELECT * FROM ... FOR UDPATE"
事先检查队列数组(?),如果队列数组不为空,则将此脚本调用放在最后的队列数组中,然后每隔几毫秒检查一次队列数组,直到队列中的数字1为止?
我在这里思考正确的方向……重要的是我现在要正确,而不是稍后回到它
编辑:有什么我可以添加以增加响应的可能性:)
解决方法:
InnoDB应该为您处理排队.如果有关于相关行的锁的事务正在进行中,那么第二个事务尝试使用另一个SELECT FOR UPDATE语句获取相同的锁,那么第二个语句将等到第一个事务提交.
你可以自己测试一下:
>打开两个bash shell窗口,并在每个窗口中运行mysql客户端.
>在每个窗口中运行START TRANSACTION.
>在第一个窗口中发出SELECT … FOR UPDATE.
>然后在第二个窗口中执行相同的操作,WHERE子句应该重叠相同的行.
>在第一个窗口中,运行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
标签:mysql,innodb
来源: https://codeday.me/bug/20190629/1327327.html