当线程/进程在获得的DB锁上崩溃时，DB如何检测并释放锁？

Question

以MySQL为例，假设线程在提交更新之前运行SELECT ... FOR UPDATE崩溃，MySQL如何检测崩溃并释放锁？

我想大多数RMDBS都会有一些保持活动的超时和/或其他陈旧连接的检测。但我找不到MySQL的确切文档。如果它确实使用了“保持活动超时”，那么MySQL将决定连接是否坏并释放锁多长时间？

如果它不保持活力，那么对于MySQL来说是什么呢？

-更新

我发现了两个相关的问题

1. 在MySQL/InnoDB中设置事务的时间限制
2. 连接丢失/断开的事务的MySQL回滚

Answer 1

这样想吧。事务中的所有更改都有一个与它们相关联的trx_id。在出现COMMIT之前，任何插入/更新/等都是“挂起”的。在某种形式的崩溃之后，未提交的trx_ids就会被清理干净。

把trx_id看作是一个“时间戳”。当您了解事务隔离模式(读-未提交、脏、read_committed等)时，这会有所帮助。

另外，请注意，虽然事务在行上有锁，但这些行的多个“版本”保存在所谓的“历史列表”中。等会儿再清理。

或者另一种方式。当进行更改时(例如插入一行)，该行实际上会放在数据库表中，但是带有一个标志(如trx_id)，表示它尚未提交。在另一个地方(“撤销”日志)，保存一个记录，这需要清理，以防崩溃。

有死锁和超时。InnoDB有一种快速发现死锁的有效方法。此时，一个冲突的事务被告知回滚；另一个被允许继续。

在不完全死锁的情况下，一个线程可以简单地等待对行的访问。这是由innodb_lock_wait_timeout控制的，默认为50秒(在我看来太高了)。如果无法在这段时间内获得所需的锁，则会回滚。

我认为除了重新启动服务器(mysqld)之外，没有什么“保持生命”，就像出现了电源故障一样。

SELECT .. FOR UPDATE获取相关行的锁(S)，以便其他线程不会在事务有机会更改行之前处理行。通常，这些锁(S)是在提交、回滚、崩溃时间或lock_wait_timeout等时间处理的，就像其他锁一样。

另见：https://stackoverflow.com/a/67807396/1766831