我正在使用连接执行事务。每当第二个连接立即尝试更新刚刚插入的行时,就找不到行。即使事务是在发出更新之前提交的。
我有mysql查询日志,它描述了这个场景。
最后一条语句失败,0行受影响(UPDATE refresh_token...):
2018-08-03T13:31:24.829038Z 1150 Query START TRANSACTION
2018-08-03T13:31:24.830026Z 1150 Prepare INSERT INTO account (<redacted>) VALUES (<redacted>)
2018-08-03T13:31:24.830493Z 1150 Execute INSERT INTO account (<redacted>) VALUES (<redacted>)
2018-08-03T13:31:24.831345Z 1150 Close stmt
2018-08-03T13:31:24.833228Z 1150 Prepare INSERT INTO refresh_token (<redacted>) VALUES (<redacted>)
2018-08-03T13:31:24.833666Z 1150 Execute INSERT INTO refresh_token (<redacted>) VALUES (<redacted>)
2018-08-03T13:31:24.834356Z 1150 Close stmt
2018-08-03T13:31:24.834477Z 1150 Prepare INSERT INTO another (<redacted>) VALUES (<redacted>)
2018-08-03T13:31:24.835155Z 1150 Execute INSERT INTO another (<redacted>) VALUES (<redacted>)
2018-08-03T13:31:24.835621Z 1150 Close stmt
2018-08-03T13:31:24.835747Z 1150 Query COMMIT
2018-08-03T13:31:24.840374Z 1150 Prepare UPDATE refresh_token SET accessed = ? WHERE token = ?
2018-08-03T13:31:24.840799Z 1150 Execute UPDATE refresh_token SET accessed = '<redacted>' WHERE token = '<redacted>'
2018-08-03T13:31:24.843346Z 1150 Close stmt如果我在发出UPDATE refresh_token SET...之前等待了500 is,就会找到记录。
以下是事务隔离级别:
SELECT @@GLOBAL.tx_isolation, @@tx_isolation;
'REPEATABLE-READ', 'REPEATABLE-READ'发布于 2018-08-03 14:16:37
不了解更多信息(如查询执行计划、受影响的行数、索引等)很难给出一个简明的答案。但REPEATABLE_READ举了一面旗子,至少对我来说是这样。
事务隔离级别是一个给予和接受的问题。它们中没有一个是“最好的”,相反,你选择一个“最适合”的。每一个都要付出代价。如果您想要较高的一致性,那么并发性就会降低。
这篇文章的摘录很好地概括了这一点:
在可重复读取中,事务期间获得的每个锁都在事务期间持有。在READ提交中,与扫描不匹配的锁将在语句完成后释放。
https://dba.stackexchange.com/questions/214008
复制相似问题