如题TiDB 悲观锁与乐观锁的适用业务场景，以及二者在事务冲突处理上的核心差异
可以看看这篇文档
其实就是事务前发现锁还是后发现锁的区别吧
乐观/悲观模型是数据库常用的2种事务模型，首先从字义上对2种事务模型进行简单区分，比如我要更新Table中的一行数据，乐观模型就是“乐观”的认为不会有其他事务也同时更新同一行数据，所以拿数据时不用加锁，最后在提交时才判断下是否有同时更新的事务。悲观模型就是“悲观”的认为会有其他事务会更新我要更新的数据，所以会在拿数据时就会加锁，这样保证自己更新时数据不会被别人再修改。
乐观/悲观事务模型的大部分使用场景：读多写少+写冲突少用乐观模型，写多读少+写冲突多用悲观模型。如果事务模型选择的“不合适”，比如高并发+写冲突高的情况下采用乐观模式，大量的retry将会带来写入的性能严重下降。本文会结合具体业务场景中遇到的写入性能瓶颈，结合TiDB的乐观事务和悲观事务，通过压测数据给出合适的选择。
关键词：分区表，写冲突，悲观/乐观事务
乐观锁提交时校验冲突，失败则重试；悲观锁事务开启即加锁，阻塞抢占避免冲突。
1.乐观锁：提交时检查，冲突报错，适合低冲突
2.悲观锁：执行时加锁，冲突等待，适合高冲突
3.金融 / 支付 / 库存 / 热点行 → 悲观锁；普通业务 → 乐观锁
乐观锁在提交时检测冲突（失败则重试），悲观锁在 DML 执行时提前加锁（冲突则阻塞等待）；适用场景上，乐观锁适合低写冲突、读多写少（如报表、缓存更新），悲观锁适合高写并发、强一致要求（如库存扣减、金融交易）。
乐观锁：执行不加锁，提交时校验版本冲突，冲突直接报错回滚，业务自行重试；TiDB 默认模式。
悲观锁：查询时立刻加行锁，冲突则阻塞等待锁释放，超时报错，需for update显式启用。
乐观锁提交校验冲突，低并发优选；悲观锁语句即上锁阻塞，高争抢场景适配。支付、库存热点行选用悲观，常规业务优先乐观。
[乐观锁：执行不加锁，提交时校验版本冲突，冲突直接报错回滚，业务自行重试；TiDB 默认模式。
悲观锁：查询时立刻加行锁，冲突则阻塞等待锁释放，超时报错，需for update显式启用。
乐观锁牺牲冲突时的“重试成本”换取常态下的“零锁开销”，悲观锁牺牲“等待阻塞”换取“提交确定性”。