MySQL事务中一致性非锁定读设SHARED_READ锁的原因及行为差异问询

问题1：事务内一致性读为何会设置看似无效的SHARED_READ锁？ #

你看到的SHARED_READ锁是元数据锁（MDL），而非InnoDB的行级锁或表级锁：

• 当autocommit=1时，普通SELECT的事务虽瞬时完成，但MySQL会自动为其添加SHARED_READ类型的MDL锁，目的是防止读取过程中其他事务执行DDL操作（如ALTER TABLE）修改表结构，导致当前读拿到的表结构不一致。
• 这个锁仅与DDL操作所需的EXCLUSIVE类型MDL锁互斥，不会阻塞DML（增删改）操作——因为DML用的是InnoDB的行级锁，和MDL锁属于不同维度的锁机制，彼此不冲突，所以看起来像是“无效”，但实际是用来保护表结构的稳定性。

问题2：两种读操作的锁类型相同，为何行为差异巨大？是否违背一致性非锁定读的定义？ #

核心原因是两种操作锁的覆盖范围完全不同：

1. 普通一致性读：仅持有SHARED_READ类型的MDL锁，没有在InnoDB层面添加任何行级锁。MDL锁只管控表结构的修改，不干预行数据的读写，所以其他事务可以正常对同表数据执行增删改（DML操作加的是行级X锁，和MDL锁无冲突）。
2. SELECT ... FOR SHARE锁定读：除了持有SHARED_READ类型的MDL锁，还会对查询匹配的行添加InnoDB的行级共享锁（S锁）。当其他事务要修改这些行时，需要申请行级排他锁（X锁），而S锁与X锁互斥，因此会被阻塞。

这完全不违背一致性非锁定读的定义：官方文档所说的“非锁定读”，特指InnoDB层面通过MVCC读取快照数据、不需要添加行级锁的机制，而MDL锁是表结构层面的保护锁，和行级锁的非锁定读属于不同范畴，二者并不冲突。

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