存储过程中的 MySQL 事务

Question

我有一个存储过程，它从多个来源收集数据，转换并最终删除，然后将数据转储到 TableA 在此存储过程运行时，其他用户经常对TableA 执行选择查询，从而导致死锁，从而导致存储过程失败。

我的存储过程在开始时确实使用了SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;，但它似乎不起作用或者我使用错误。

如果不使用READ/WRITE LOCKS，有什么方法可以确保不会发生这种情况？

MySQL 版本：5.7.23-enterprise-commercial-advanced-log

Answer 1

我有很多 cmets：

• 我假设您使用的是SELECT ... FOR UPDATE，因为没有可选的锁定子句，SELECT 不会获取行锁，因此不会导致死锁。

• 没有FOR UPDATE 子句的其他读取查询不需要行锁。它们不会导致死锁。

• 为了防止死锁，您需要使用原子锁。考虑LOCK TABLES。

• 更改隔离级别对当前运行的事务没有影响。如果您已经有一个事务在进行中，则不能即时更改其隔离级别。对隔离级别的更改仅适用于您随后开始的事务。

• READ UNCOMMITTED 隔离级别并不能消除查询获取锁的需要，如果它们需要其他隔离级别的锁。

• 在使用 MySQL 的 20 多年中，我从未发现 READ UNCOMMITTED 的合法用途。我避免它。