READ-COMMITTED隔离级别下MySQL DELETE为何等待未提交行锁？

1. DML锁的执行逻辑优先级 #

InnoDB执行DELETE这类DML操作时，先通过索引定位记录并加锁，再检查非索引条件：

• 事务2的delete语句依赖主键索引做范围扫描（CITYID>=3 and CITYID<=10），InnoDB会遍历主键索引中所有落在该范围内的记录——包括事务1未提交的CITYID=8（主键索引项在插入时已实时写入，仅标记为未提交状态）。
• 遍历到CITYID=8时，事务2会尝试加排他锁（X锁），但事务1因插入操作已持有该记录的X锁，因此事务2进入等待状态。

2. READ-COMMITTED隔离级别的作用边界 #

RC隔离级别仅控制读操作的可见性（读操作只能看到已提交的记录），但不改变DML操作的锁获取规则：

• 对于DML操作，InnoDB必须锁定所有可能符合条件的记录（包括未提交的记录），因为事务1可能后续提交，这条记录会成为有效数据，若不提前锁定会引发数据一致性问题。

3. 半一致性读的局限性 #

RC隔离级别下的半一致性读特性（针对UPDATE操作，读取已提交版本判断是否需要加锁）仅适用于单条记录的定位更新，对于范围扫描的DML操作（如本次的范围DELETE），该特性不会触发，因此事务2仍会尝试锁定所有索引范围内的记录，包括未提交的CITYID=8。

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