只读事务仍可能加锁，因其虽不执行DML，但SELECT...FOR UPDATE或无索引查询会触发行锁、间隙锁或意向锁；RR下普通SELECT依赖MVCC快照，但快照构建及后续当前读均需加锁。
只读事务为什么还会加锁？
MySQL 的“只读事务”不是字面意义的“不加任何锁”，而是指不主动执行 INSERT/UPDATE/DELETE。但只要用到 SELECT ... FOR UPDATE 或 SELECT ... LOCK IN SHARE MODE，或者在可重复读（RR）隔离级别下执行普通 SELECT（配合 MVCC 快照），InnoDB 仍可能隐式加锁——尤其是当查询走不到索引、触发间隙锁或需要一致性读视图时。
RR 隔离级别下普通 SELECT 的锁行为
在默认的 REPEATABLE READ 隔离级别中，一个纯 SELECT 不显式加锁，但会建立一致性读视图（MVCC snapshot）。问题在于：这个视图的构建过程本身可能依赖锁。
- 如果事务中先执行了
SELECT ... FOR UPDATE，后续所有SELECT都复用同一快照，但该快照起点受第一个加锁语句影响 - 若事务开启后第一个语句是
SELECT * FROM t WHERE id = 100（有索引），通常不加锁；但如果是SELECT * FROM t WHERE name = 'xxx'且name列无索引，InnoDB 可能退化为全表扫描 + 为每行记录生成隐藏版本链，期间仍需获取意向锁（IX），并可能被其他事务的X锁阻塞 - 更隐蔽的是间隙锁（gap lock）：哪怕只查一行，如
SELECT * FROM t WHERE id > 5 AND id ，RR 下会锁住 (5,10) 这个区间，阻止其他事务插入新行——此时另一个事务执行 <code>INSERT INTO t VALUES (7, ...)就会被阻塞
哪些只读操作实际会触发锁等待
以下操作看似只读，却可能让事务陷入锁等待：
-
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE：明确加行级 X/S 锁，等待持有冲突锁的事务释放 - 在 RR 级别下执行
SELECT前，事务已通过其他语句（如UPDATE）持有了锁，后续SELECT虽不加新锁，但整个事务仍处于活跃锁持有状态，阻塞他人 - 使用
SELECT触发隐式锁升级：例如某些 ORM 框架（如 Hibernate）在 lazy load 关联对象时，自动生成带FOR UPDATE的语句；或 Spring 的@Transactional(readOnly = true)并未禁用底层 SQL 的锁提示 - 元数据锁（MDL）：即使是
SELECT，访问表时也会申请 MDL 读锁；若此时有 DDL 正在等待 MDL 写锁（如ALTER TABLE），而该 DDL 又被前面的长事务阻塞，则你的只读事务也会卡在 MDL 等待队列里
如何确认只读事务是否真“无害”
别信 readOnly = true 标签，得看实际执行的 SQL 和锁状态：
- 查
information_schema.INNODB_TRX，重点关注TRX_STATE = 'LOCK WAIT'且TRX_ISOLATION_LEVEL = 'REPEATABLE READ'的事务，再结合TRX_QUERY看它卡在哪条SELECT - 运行
SHOW ENGINE INNODB STATUS\G，翻到 “TRANSACTIONS” 部分，找 “*** (1) WAITING FOR THIS LOCK TO BE GRANTED:” 后面的锁类型和记录 - 检查
performance_schema.data_lock_waits（MySQL 8.0+），直接看到谁在等谁、等什么锁、等待多久 - 特别注意
State列为Locked或Waiting for table metadata lock的线程，它们往往就是被只读事务拖住的“受害者”
真正麻烦的从来不是“有没有锁”，而是“锁住了什么、持有多久、谁在等它”。一个没提交的只读事务，可能比一个快速写事务更危险——它不改数据，却悄悄焊死连接、锁住间隙、堵住 DDL。
