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之前没有悲观事务，我都不会向老板推荐。 