- 【TiDB 版本】：3.0.9
- 【问题描述】：慢查询中出现大量相同 update 语句并影响数据库性能
查询错误日志出现 【Lock wait timeout exceeded; try restarting transaction】错误
业务场景：增加一个用户，需要在上级用户字段上进行累加
该业务存在高并发的情况。
这种情况下我们应该怎么做优化，是从数据库优化入手还是业务呢？
1、先确认下这个是开启了悲观锁模式吗？
2、如果是出现了锁等待超时，建议从下面角度进行调整，请评估：
1）持有锁的事务需要尽快提交，释放锁资源，避免长时间持有锁的情况发生
2）如果是简单事务，建议查看下相关 sql 的执行计划，排除下是否是因为执行效率过低，导致持有锁的时间过长
如何确定是否开启悲观锁模式， 我们将【tidb_disable_txn_auto_retry】重试设置为 【0】 关闭状态， 业务很简单，但是语句也很简单，但是可能会出现抢锁严重的情况。 update a set c_num = c_num + 1 where user_id = ?
这个是表示悲观锁模式开启么，业务代码用的springboot + mybatis 框架，没有使用手动提交模式。
看配置文件是悲观锁。。连接一个tidb，看一下 SELECT @@global.tidb_txn_mode ， 返回值是optimistic或者’'，为乐观锁模式；返回值是pessimistic，为悲观锁模式。。觉得语句如果是在悲观锁模式下，最简单的方法是在user_id上创建索引，减少锁的行数。。要么就只有尽快commit了。。
不知道回答的对不对。
1 个赞
检查了确实在悲观锁模式，user_id上已经带了索引了，锁的只有单行，如果想修改成乐观锁应该怎么操作呢 ? 单行commit的话我可以用异步操作不在同一个事务里面提交吧。
已经关闭了悲观锁模式，暂时没有发现这种情况了。谢了。
感谢回复
如有新的问题，请另开新帖提问哦～
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。