【TiDB 版本】：
3.0.5
【问题描述】：
1 异常
Write conflict, txnStartTS=412969113333792769, conflictStartTS=412969113320685577, conflictCommitTS=412969113543507969, key={tableID=4696, handle=56563} primary={tableID=4696, indexID=1, indexValues={0003ee7b74614ad6a141d46a0cdf6ba0, }} [try again later]
2 高并发修改操作情况下，写冲突比较多，我还能从哪些角度去思考这个问题？
1 针对大量冲突场景使用 悲观锁
使用悲观锁，为了保证数据完整性，一定会影响性能
2 开启事务重试
开启事务重试，会影响最后更新的数据结果不准确
除以上我能想到的，还有哪些更好的解决方案？
1、事务重试部分也可以交由应用端处理
2、开启悲观事务后，两个 session 更新相同的目标数据，观察下 session 的行为。以下示例仅供参考：
1 老师，这个要应用端捕获TiDB的异常来进行重试，是这个意思吗？
2 单机多KV是不是也容易造成写冲突
3 应用程序使用的是16线程并发1600条数据，写冲突就很严重，这会是什么原因？
gaozhenjiao
(Hacker O Kes Ks Fz)
4
冲突取决于业务模式和特点，需要从业务的角度自行分析。原则上与 kv 的节点数量关系不大
1 个赞
优化程序了，在并发的情况下，尽量以处理数据时，减少修改同一条数据。
system
(system)
关闭
7
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。
