Q1

2

4

5

Q2

read committed

语句2读自己的修改，2000
read committed只允许读取其他事物已提交的数据，所以语句4读到的是1000
语句5读到的是session1回滚+commit的结果，即1000

2

4

5

repeatable read

repeatable read 当两个事务同时进行时，其中一个事务修改数据对另一个事务不会造成影响，即使修改的事务已经提交也不会对另一个事务造成影响；不允许脏读。
故语句4读到1000。

2

4

5

serializable

serializable 强制两个事务串行执行，故session 1没commit之前session 2无法读取id为1的数据，尝试读取直至被阻塞超时

2

4

5

Q3

2

4

Q4

repeatable read

repeatable read 不允许不可重复读，故session1在语句4再次读的时候没有受到session2修改的影响，仍是0

2

4

serializable

serializable不允许不可重复读，故session1在语句4再次读的时候没有受到session2修改的影响，仍是0

2

4

Q5

session2无法在session1设置s锁后进行读/写，直到session1 commit，锁释放。
所以T2时无法修改，T4时修改money = 1000

T2

T4

Q6

2 初始，读到id=1,2

4 可重复读不允许不可重复读，故session2新加的id=3没被读到，只读到Id=1,2

6 自己写自己读，读到id=1 2 3

7 可重复读允许幻影读，事务内的SELECT语句基于事务开始时的快照，不会看到其他事务提交的新数据（如id=3），而UPDATE会读取最新的已提交数据（即使其他事务在之后提交），故对id=3进行修改后，session1读到了id=1 2 3

Q7

2

4

Q8

repeatable Read

• 现象：语句2增加 LOCK IN SHARE MODE 后session2 的语句5需要获取插入意向锁，与共享锁冲突，导致阻塞。
• 原因：S锁允许其他事务读同一范围，但禁止写入等操作。

serializable

• 现象：即使语句2 不加 LOCK IN SHARE MODE，session1 的普通 SELECT 也会隐式加锁（如表锁或范围锁）。session2 的 INSERT 仍然被阻塞，原因与可重复读相同。
• 关键区别：Serializable 隐式加锁范围更严格，普通查询也可能导致锁冲突。

Q9

serializable只允许事务串行执行，session1 commit之前对id=1加排它锁，session2的语句2需要获得id=1的排它锁，但x锁互斥，故无法执行delete操作，commit后session1释放排它锁，语句3正常执行

2

3

Q10

1. A执行 UPDATE tableA SET columnA=1 WHERE id=1，对 tableA 中 id=1 的行加 排他锁（X锁）。
2. B执行 UPDATE tableB SET columnB=2 WHERE id=1，对 tableB 中 id=1 的行加 排他锁（X锁）。
3. A尝试执行 UPDATE tableB SET columnB=3 WHERE id=1，需要获取 tableB 中 id=1 的 X锁，但该锁已被B持有，A进入等待状态。
4. B尝试执行 UPDATE tableA SET columnA=2 WHERE id=1，需要获取 tableA 中 id=1 的 X锁，但该锁已被A持有，B也进入等待状态。此时双方事务互相等待对方释放锁，形成循环等待，触发死锁。