线上交易系统多线程并发更新同一批订单数据，频繁出现 Lock wait timeout exceeded 报错，更新任务失败；串行执行更新语句不会出现报错，集群 TiKV 资源充足，无磁盘满、Region 热点等问题。
1 个赞
大量删除后空间不释放检查GC safepoint是否正常推进。
高并发更新同一个key导致。
多线程并发争抢同一批订单行 key，乐观事务写入前会加短时行锁；先拿到锁的事务未提交释放，后续事务排队等待，超过锁等待阈值就抛出Lock wait timeout exceeded；串行无竞争所以不会超时。
1 个赞
如果允许可以切换悲观事务，适配高并发更新场景，缓解行锁争抢
2 个赞
多线程并发更新同批数据引发行锁竞争、锁等待超时，串行无冲突故正常，TiKV 资源与热点均无异常。
2 个赞
更新订单这类高并发争抢场景改用悲观模式，操作前先加行锁，从底层减少锁等待排队。
降低并发粒度、拆分更新语句、缩短事务时长、调整锁等待超时参数。
你这个 Lock wait timeout exceeded 报错，是多线程并发更新同一批数据时，乐观事务的锁冲突等待超时导致的。建议优先从业务侧优化：控制并发度，避免多个事务同时修改同一行热点数据，同时缩短事务执行时间，减少锁持有窗口；也可以在更新语句中配合 FOR UPDATE 显式加锁，或使用 TiDB 的悲观事务模式（SET @@tidb_txn_mode = 'pessimistic';），让事务在执行阶段就获取锁，避免乐观提交阶段的冲突；如果并发确实很高，还可以适当调大 innodb_lock_wait_timeout 参数延长锁等待时间，同时排查是否存在长时间未提交的事务阻塞其他更新，从根源上缓解锁竞争问题。
GC safepoint受最早活跃事务的start_ts限制。
感谢老师分享
1 个赞
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。