最近把订单库从 MySQL 迁到 TiDB 6.5，300 多并发写入时经常报 write conflict，看日志应该是乐观事务冲突。我试过把大事务拆小、应用层加了重试逻辑，冲突少了一些，但高峰期还是会冒出来。想请教一下：直接把事务模式切成 pessimistic 稳不稳？对写入吞吐影响大不大？大家生产环境一般怎么选？另外 tidb_retry_limit 有没有推荐值？感谢！
write conflict 本质是乐观事务在 commit 阶段做两阶段提交时，TiKV 会校验事务 start_ts 到 commit_ts 之间读写集是否被其他事务改动，冲突就回滚。订单库这种热点行更新（比如库存扣减、状态流转）用乐观模式必然高冲突。直接切 pessimistic 是稳的，它在 DML 阶段就加悲观锁，把冲突提前到加锁时串行化，避免 commit 时才失败，代价是锁等待和额外 RPC，吞吐会降但更可控。
1 个赞
拆事务、加重试这个思路没问题。不过先确认下 tidb_txn_mode，6.5 默认其实就是悲观模式，可能是被驱动或迁移工具改回乐观了。另外高峰扎堆的冲突多半是热点问题，订单表自增主键会把写入压在少数 region 上，换成 AUTO_RANDOM 能缓解不少，可以先用 Dashboard 的 Key Visualizer 看一眼。悲观模式我们生产订单场景跑了一年多，吞吐略降但延迟稳，放心切。重试次数保持默认 10 就行，乐观下的写冲突服务端本来就不会自动重试，最终还是得靠应用层兜底。