【 TiDB 使用环境】 测试
【 TiDB 版本】V6.1
【复现路径】我们这个场景是 2个 进程，第一个发完insert命令发消息给后面MQ，进程自己就关闭了，第二个业务进程取到消息继续做业务，然后update这条记录eg：type=4，此时单条场景都不失败，但是批量这种任务做的时候，有概率update失败~
【遇到的问题：问题现象及影响】
【资源配置】*
【附件：截图/日志/监控】
希望大家帮分析下~
慢查询里能看到update吗？
是什么表现？update语句报错，还是update数值错误？
1 个赞
有概率update失败 具体失败结果是什么
update重复执行的吧
代码层打印，返回的影响行数都是1 但是去库里查 数据没更新，然后我们在更新后 ，用代码直接取又能取到数据 taskData是被更新的，仅仅在当前这个进程中可以读到，如果在db工具里去看数据 ，数据是未更新。。。。然后用另一个接口去用PK读取也读不到
代码层打印，返回的影响行数都是1 但是去库里查 数据没更新，然后我们在更新后 ，用代码直接取又能取到数据 taskData是被更新的，仅仅在当前这个进程中可以读到，如果在db工具里去看数据 ，数据是未更新。。。。然后用另一个接口去用PK读取也读不到，MQ的消息是只取一次，应该不会重复执行了
看了下 并没有这个慢查询日志
然后我们在更新后 ，用代码直接取又能取到数据 taskData是被更新的，仅仅在当前这个进程中可以读到，如果在db工具里去看数据 ，数据是未更新
看上去是个典型事务控制问题。
需要关注你的代码是怎么控制事务的，是不是有什么框架配置了事务管理器帮你开启了事务，特别是update的这个进程，怎么看都像是这个里面开了一个非自动提交的事务，但又没有commit。
我们刚测试的时候 如果在 执行update的进程中 sleep 500ms ，这个update就能100%成功~评估如果是事务。。应该不会被这个 insert和 update中间的500ms 影响
另外另一个测试的场景，10个这样的任务，其中可能一部分update是成功的，一部分是不成功的
既然这么好复现，强烈建议，直接把代码贴出来。我也试试。
是不是又阻塞或者锁呢
你是怎么执行的update 控制台执行sql还是代码？
那这个出现概率很高啊，建议贴一下代码语句，大家复现一下试试
1 个赞
返回的影响行数都是1 然后是不是没有commit.
批量的时候锁冲突，导致有些事务回滚了。
1 个赞