悲观事务的疑问

🪐 TiDB 技术问题
1

关于 TiDB 悲观事务与乐观事务，以下说法正确的有：
A. 悲观事务默认会对涉及的行加锁，能大幅降低事务冲突
B. 乐观事务冲突时会报 WriteConflict，需要业务重试
C. 悲观事务一定比乐观事务性能更好
D. 大事务、高冲突场景更适合悲观事务
E. 开启悲观事务后，事务超时时间可以完全不用关注

2

悲观事务，悲观锁和乐观事务这块一直不是很理解

3

选择B乐观锁也要检测冲突

4

A、B、D

5

C. 悲观事务一定比乐观事务性能更好 ---- 错误
低冲突、读多写少场景：乐观事务更快（无加锁开销）
高冲突场景：悲观事务更优
不存在 “一定更好”。

6

E. 开启悲观事务后，事务超时时间可以完全不用关注----- 错误
悲观事务持有锁时间过长依然会：
导致其他事务阻塞
触发锁等待超时
引发性能雪崩
事务执行时间依然需要严格控制。

7

选择 A B D

1 个赞
8

C E太绝对了 不选

1 个赞
9

A,B,D就这三个

10

C. 悲观事务一定比乐观事务性能更好 。 悲观事务加锁有开销，低冲突场景下性能通常不如乐观事务，并非一定更好。
E. 开启悲观事务后，事务超时时间可以完全不用关注。悲观事务同样存在锁等待、事务超时等问题，仍需合理设置超时时间。
所以我选ABD

11

什么样的事务是悲观事务

12

我感觉选A和D

13

B. 正确

乐观事务基于多版本并发控制（MVCC），不提前加锁，在事务提交时才检测冲突。如果检测到写冲突，会直接返回 WriteConflict 错误，需要业务侧进行重试。

D. 正确

大事务、高冲突场景下，乐观事务极易出现大量 WriteConflict 重试，性能急剧下降；而悲观事务通过提前加锁，避免了冲突重试，更适合这类场景。

  • 互联网高并发业务（如电商、社交）：优先用乐观事务，低冲突场景性能最优
  • 金融核心、高冲突大事务（如转账、账务）：选择悲观事务，保障数据一致性，避免重试
14

A倒是也正确就是加锁也是有代价的

15

正确答案是ABD
其中A 认为是错误的 可能是因为 混淆了显式加锁语句和悲观事务的默认加锁机制，悲观事务的本质就是默认对写操作涉及的行加锁，这是 TiDB 官方明确的设计。

16

是的，加锁会降低事务冲突但是也有会加锁的代价

17

是单选题吗? 我选b

18

ABD

19

ABD，另外两个的表述太绝对

20

AB肯定对