SQL：在 REPEATABLE READ 隔离级别下，UPDATE 锁是否保持到事务结束？
我已经阅读有关REPEATABLE READ如何导致锁定的信息通过 SELECT 语句保持到事务结束。 UPDATE 语句所采用的独占锁也是如此吗？因此，当我在事务中更新一行时，后续的 SELECT 是否会返回 UPDATE 留下的值？
所以我明白，如果我在事务 1 中选择一行，那么事务 2 就无法更新它，直到事务 1 完成。但是，如果我 UPDATE 事务 1 中的行，那么事务 2 是否仍然需要等待事务 1 完成，然后事务 2 才能更新它？
I have read about how REPEATABLE READ causes locks held by SELECT statements to be held to the end of the transaction. Is the same true for exclusive locks taken by UPDATE statements? Consequentially, is it the case that when I UPDATE a row in a transaction, subsequent SELECTs will return the value left by the UPDATE?
So I understand that if I SELECT a row in transaction 1, then transaction 2 cannot UPDATE it until transaction 1 completes. However, if I UPDATE The row in transaction 1, will transaction 2 still have to wait for transaction 1 to complete before transaction 2 can UPDATE it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
除非第二个事务在隔离级别 READ UNCOMMITED 下运行，否则第一个事务中 UPDATE 语句获取的独占锁将阻止任何选择，直到第一个事务提交。
是的。
如果在 REPEATABLE READ 下，您在事务 1 中执行 SELECT，事务 2 仍然可以添加与事务 1 中 SELECT 的 WHERE 子句匹配的新数据。这是因为事务 1 对所有事务都设置了行读锁。检索数据但未检索范围锁。
Unless a second transaction is running at Isolation level READ UNCOMMITED, exclusive locks taken by UPDATE statements in the first transaction will block any selects, until the first transaction commits.
Yes.
If under REPEATABLE READ, you perform a SELECT in transaction 1, transaction 2 could still add new data that matches the WHERE clause of the SELECT in transaction 1. This is because transaction 1 places row read locks on all retrieved data but not range locks.