MariaDB事件中设置事务隔离级别是否仅作用于当前会话？

你在事件中使用SET SESSION TRANSACTION ISOLATION LEVEL设置的事务隔离级别仅作用于该事件运行时的专属临时会话，不会对全局或其他任何会话产生影响。

原因解释 #

MariaDB/MySQL的事件调度器每次执行事件时，都会创建一个独立的专属临时会话来运行事件逻辑：

• 这个会话拥有独立的会话级配置空间，所有SET SESSION开头的参数修改都仅在该会话内生效
• 事件执行完成后，这个临时会话会立即被销毁，所有会话级的配置修改也会随之消失，不会残留到其他会话或全局配置中

关于你的代码补充 #

你在事件末尾手动重置隔离级别的操作：

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

其实不是必须的——因为会话销毁后设置会自动失效，但手动重置是个严谨的好习惯，尤其是如果后续需要扩展事件逻辑、在同一个会话内执行其他需要默认隔离级别的操作时。

验证方法（可选） #

如果想确认隔离级别的作用范围，可以在事件中添加日志记录：

BEGIN
    SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
    -- 记录当前会话的隔离级别到日志表
    INSERT INTO event_log (event_name, tx_isolation, log_time)
    VALUES ('event_name', @@transaction_isolation, NOW());
    /*<你的复制逻辑代码>*/
    SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
END$$

然后在事件外部执行查询，查看全局隔离级别：

SELECT @@global.transaction_isolation;

对比日志表中的记录和全局级别，就能确认会话级修改没有影响全局。

结合你的场景说明 #

你选择READ UNCOMMITTED解决死锁的思路是可行的：这个隔离级别下，INSERT INTO SELECT中的读操作不会对源表加共享锁，因此不会和生产环境中对源表的写操作产生锁冲突，从根源上避免了死锁。而由于是会话级设置，生产环境其他业务会话的隔离级别不受任何影响，依然保持原有数据一致性保障。

内容的提问来源于stack exchange，提问作者andregoncalves