在MySQL 8.0中如何理解只读事务与读写事务的锁差异-mysql教程-PHP中文网

mysql只读事务默认不加锁，但普通select的“无锁”仅限快照读（mvcc+readview），当前读（如for update）仍会加锁并报错；隔离级别决定readview创建时机及是否启用间隙锁。

在mysql 8.0中如何理解只读事务与读写事务的锁差异

只读事务默认不加锁，但`SELECT`是否真“无锁”取决于隔离级别和语句类型

MySQL 8.0 中，START TRANSACTION READ ONLY 声明的事务本身不获取写锁，也不隐式升级为读写事务；但它执行的 SELECT 仍可能触发锁——关键看是不是“当前读”。比如 SELECT ... LOCK IN SHARE MODE 或 SELECT ... FOR UPDATE，哪怕在只读事务里也会加 S 锁或 X 锁，违反只读约束并报错 ER_XA_RBTIMEOUT 或 ER_READ_ONLY_TRANSACTION。

真正“无锁”的是快照读（snapshot read），即普通 SELECT。它依赖 MVCC 读取事务开始时的 ReadView，不阻塞其他事务，也不被其他事务阻塞。但注意：在 READ COMMITTED 级别下，每次 SELECT 都新建 ReadView；而在 REPEATABLE READ 下，只在第一次 SELECT 时创建，后续复用——这直接影响幻读行为和间隙锁是否生效。

READ COMMITTED：快照读不加锁，但当前读（如带 FOR UPDATE）会加行锁 + 无间隙锁
REPEATABLE READ：快照读不加锁，当前读则加 Next-Key Lock（行锁 + 间隙锁），防止幻读
显式声明只读事务后，若执行了任何修改语句（INSERT/UPDATE/DELETE），MySQL 会立刻报错并中止事务

`READ ONLY` 事务对间隙锁（Gap Lock）的实际抑制效果有限

很多人误以为只读事务就“不参与间隙锁竞争”，其实不然。间隙锁本质是为防止幻读而设，由**当前读语句触发**，与事务是否只读无关。例如：

START TRANSACTION READ ONLY;
SELECT * FROM account WHERE balance > 1000 FOR UPDATE; -- ❌ 报错：只读事务不能加锁
SELECT * FROM account WHERE balance > 1000 LOCK IN SHARE MODE; -- ❌ 同样报错

但如果只做普通 SELECT，那根本不会进入加锁路径，自然也谈不上间隙锁。所以“抑制间隙锁”不是只读事务的功能，而是“不做当前读”的结果。反过来，如果你在读写事务里只做快照读，同样不产生间隙锁。

间隙锁只出现在 REPEATABLE READ 级别下的当前读、范围查询、唯一索引等特定场景
READ ONLY 事务无法绕过隔离级别规则——它只是禁止写操作，并不改变 MVCC 或锁的底层行为
想彻底避免间隙锁？要么降级到 READ COMMITTED，要么确保所有查询都是快照读且无范围条件

读写事务在 `REPEATABLE READ` 下的锁升级路径更复杂

读写事务（START TRANSACTION 或 START TRANSACTION READ WRITE）一旦执行写操作，InnoDB 就会按需申请锁，并可能触发锁升级。例如：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

UPDATE 匹配到记录 → 加记录锁（Record Lock）
UPDATE 匹配不到记录但存在范围 → 加间隙锁（Gap Lock）
UPDATE 是范围条件（如 WHERE balance BETWEEN 500 AND 1500）→ 加 Next-Key Lock（覆盖记录+间隙）
后续相同条件的 SELECT ... FOR UPDATE 会复用已有锁，也可能触发锁等待甚至死锁

而只读事务从一开始就被禁止走这条路径。它的“轻量”不是因为锁少，而是因为它被拦在了加锁入口之前——你连 FOR UPDATE 都执行不了，自然不会触发锁升级逻辑。