【 TiDB 使用环境】测试
【 TiDB 版本】7.1
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
看文档tidb存在 乐观锁和悲观锁，这两种锁文档说法是乐观锁在冲突少时候开销比较小，但是没具体说开销小在哪里，是cpu还是io占用。如果不考虑锁冲突，就更新性能来说，乐观锁性能能高大概多少？
tidb的锁都是通过往kv 写Lock数据实现的，悲观模式时DML阶段就写入悲观锁到tikv，之后提交时Prewrite+commit和乐观一样，写数据写乐观锁到tikv。
如果不存在锁冲突，性能有差距吗
没感受出来有多大差距，最好是自己测一下
https://docs.pingcap.com/zh/tidb/stable/dev-guide-optimistic-and-pessimistic-transaction#乐观事务和悲观事务
简单的讲，[乐观事务](https://docs.pingcap.com/zh/tidb/stable/optimistic-transaction)模型就是直接提交，遇到冲突就回滚，[悲观事务](https://docs.pingcap.com/zh/tidb/stable/pessimistic-transaction)模型就是在真正提交事务前，先尝试对需要修改的资源上锁，只有在确保事务一定能够执行成功后，才开始提交。
对于乐观事务模型来说，比较适合冲突率不高的场景，因为直接提交大概率会成功，冲突是小概率事件，但是一旦遇到事务冲突，回滚的代价会比较大。
悲观事务的好处是对于冲突率高的场景，提前上锁的代价小于事后回滚的代价，而且还能以比较低的代价解决多个并发事务互相冲突导致谁也成功不了的场景。不过悲观事务在冲突率不高的场景并没有乐观事务处理高效。
从应用端实现的复杂度而言，悲观事务更直观，更容易实现。而乐观事务需要复杂的应用端重试机制来保证。
相信我，没几个研发人员喜欢乐观事务，你用乐观事务意味着他们的工作量要提升了。tidb之前没有悲观事务，我都不会向老板推荐。 
如果能确认这个操作不会有冲突，那用了也没事的，有些业务确实不会出现冲突
1 个赞
我们测试过一次，2倍左右，OA场景
1 个赞
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。