再次补充： 我们尝试通过tikv_rust_client进行一个乐观事务请求（包含一个删除和一个更新） 第一次请求发生resolve_lock error 第二次重试发生committed错误，并且在tikv日志中我们也发现了这个错误的日志！日志如下： [2025/10/30 07:16:31.509 +00:00] [ERROR] [errors.rs:487] [“txn aborts”] [err_code=KV:Storage:Committed] [err=“Error(Txn(Error(Mvcc(Error(Committed { start_ts: TimeStamp(…

感谢，我需要 tikv-wg 的工作区管理员邀请才能登陆这个网站，如果可以的话，请邀请下这个email：ytypy9348@gmail.com

我看了一下admin check table，这个命令似乎是检查主表和其索引的一致性(index条目数量以及对应列的值是否正确)，我的问题可能与此无关，我补充下我们的问题场景：我们没有用tidb，而是直接用的tikv_client，向tikv写入kv对，使用了tikv_client 提供的事务接口（不是raw），如tx.set, tx.commit等，上层也没有实现索引相关的东西。另外我想问一下，committed错误报错的场景是什么？是哪一步检查没能通过导致了该问题？

看链接中的意思是，v8.3之后，LOCK IN SHARE MODE 实际上并不能保证读读共享，依然是一个普通的排它锁？后续pingcap有考虑实现一个真正的读写锁吗

我也有楼主一样的问题。 SELECT … FOR UPDATE是行锁没错，但是如果不是为了修改这一行，而仅仅是为了避免在修改其他行的时候，这一行被其他事务篡改，那么能否把这行数据改成 行-读 锁，允许事务A和事务B同时对该行施加读锁， 从而修改各自的其他数据。 例如，事务A需要修改key a, 但是要求key z存在；同时，事务B需要修改key b, 也要求key z存在；我希望的是这2个事务能够并行完成。