MySQL会话级事务隔离级别设置及多级别并发问题咨询

1. 为什么MySQL按会话设置事务隔离级别？ #

不同业务场景对事务隔离性和性能的需求差异很大：比如后台报表查询需要强一致性，适合用Repeatable Read（RR）甚至Serializable；而高频写入的业务，为了追求性能，可能用Read Committed（RC）降低锁开销。按会话设置隔离级别，能让每个数据库连接根据自身业务需求灵活调整，不用修改全局配置影响其他会话。另外，有时候需要临时调整某个会话的隔离级别来排查问题，这种方式也更灵活，不会对整个服务造成影响。

2. 为什么MySQL中多个设置不同事务隔离级别的会话操作同一张表不会产生冲突？ #

核心原因是InnoDB的多版本并发控制（MVCC）和精细化锁机制的配合：

• MVCC会为每个事务生成独立的数据快照，不同隔离级别的会话看到的是符合自身隔离规则的数据版本，读操作大多不需要加锁，避免了读和读、读和写的冲突。
• InnoDB的锁是行级锁（及间隙锁），只有当不同会话操作同一行数据，且操作类型（读/写）触发锁竞争时才会产生冲突，而不同隔离级别只是决定了锁的范围和快照的生成规则，只要不是针对同一资源的竞争性操作，就不会互相干扰。

3. 若事务A为Repeatable Read级别、事务B为Serializable级别，当事务B运行时事务A会出现什么情况？ #

分场景来看：

• 如果事务A是只读操作：因为RR级别用MVCC的一致性读，读取的是事务启动时的快照数据，不需要加锁，所以不会被事务B阻塞，能正常执行。
• 如果事务A是写操作（插入/更新/删除）：
  • 若操作的行或数据范围被事务B的间隙锁/行锁覆盖，事务A会被阻塞，直到事务B提交或回滚释放锁。
  • 若操作的资源不在事务B的锁范围内，事务A可以正常执行，不会受影响。
• 如果事务A执行当前读操作（比如SELECT ... FOR UPDATE）：同样会因为锁竞争被事务B阻塞，直到事务B结束。

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