[image] [image] [image] 从 CheckTxnStatus 的代码上面看，好像如果待检查的 primary lock 超时的话，写入的回滚记录并不是保护类型的呢？和您所说的逻辑有出入

多谢您解惑 这个流程涉及多个接口的交互，的确理解起来比较困难了。我后续可能会为这段代码添加足够的注释，让后面的 contributor 更容易的理解

check txn status 的时候，如果发现 primary 锁已经超时，会进行立刻回滚的。 关于回滚时候发现了提交记录，为何一定要 panic，那就是 tikv 的同学认为这种是非常严重的问题了，肯定是哪里有 bug，需要提前定位，立刻解决

是这样的，回滚的过程中发现事务已经提交了，那肯定哪里有 bug 了。singleRecord 的记录可能是提交记录，也可能是回滚记录

乐观事务 t1 开始进行二阶段提交 发送了 prewrite，tikv 收到了，但是由于网络原因一直没有发送到 tidb 客户端 tidb 客户端进行了 prewrite 重试，由于网络原因阻塞，tikv 没有收到。 乐观锁超时 并发事务 t2 调用了 checktxnstatus发现事务已经超时，开始进行 resolve lock，resolve lock 进行了回滚，并且 是 non-protected 级别的，没有任何 rollback 记录 网络原因 tikv 突然又收到了之前的 prewrite 我所说的场景肯定不会出现是吗？ [image]

多加锁肯定正确性有提升，但是相应的系统压力也变大了 而且也确实想不到什么场景必须加才可以保证正确性

@dba远航 @WinterLiu 这个问题就是使用悲观锁的过程中，TIDB 的实现是不止对 rowID 进行了加锁，而且还对唯一索引加了锁。 这么做的核心原因是什么呢？ 除了 INSERT 新的唯一索引 value 和 update 新的唯一索引以外，感觉并不需要对唯一索引加锁，只需要对 rowID 加锁即可实现悲观锁

@gcworkerishungry @lemonade010 多谢大家的回复

@lilinghai @tidb菜鸟一只 @dba远航 @lemonade010 多谢大家的回复

通过 DEBUG tikv 的代码： [image] 可以总结有两种场景： 如果只有悲观事务，那么 RC/RR 级别的 select 快照读会忽略其他悲观事务加的锁。例如有两个悲观事务，一个事务t1 执行 select for update，不提交，另一个事务 t2 执行 select 快照读。虽然 t2 快照读发送给 tikv 的请求仍然是 si 级别的，也检测到了 t1 事务所加的悲观锁，但是会主动忽略这个锁，而直接返回上一个 commit 记录，无需等锁或者重试 如果悲观事务和乐观事务共存，RC/RR 级别的 select 快照读可能会遭遇等锁、重试。例如两个事务，一个事…

通过 debug TIDB 和 TIKV 的代码发现： select * from managers where first_name=‘brad8’; 语句未能命中索引，因此没有使用 tidb 的 pointget 而是 coprocessor。因此调用的 tikv 接口不是 batchget 而是 coprocessor TIDB 即使对于 RC 级别的快照读，也会对 TIKV 使用 SI 隔离级别的 get/coprocessor 请求。对此， TIKV 的代码特意针对 SI 级别的快照读进行特殊判断，不检测悲观锁的锁冲突，用于防止 select 快照读请求被其他悲观事务阻塞…

你应该学习过课程，能否请教一下，tidb 是否可能有一层缓存数据，可以直接处理 RC 级别的 select 快照读请求，而不需要发送 rpc 给 tikv 呢？

是的 后期估计也会改成 Fair Locking 的名字，目前还没改

select * from t where id=1 for update; 语句表中没有 id = 1 的记录场景下， 如果不加锁的话，是否需要担心有并发事务 insert 了一条 id = 1 的记录呢

请指教一下，有没有官方文档写 select for update、delete、update、insert 等语句更新一条数据、更新多条数据的加锁流程呢，最好带有举例的那种。 多谢多谢

我又看了一遍 tidb 配套的设计： https://github.com/pingcap/tidb/pull/37518/files 感觉大部分看懂了。 但是对这个流程好像还是不太了解： When a key is locked with conflict, the current statement becomes executing at a different snapshot. However, the statement may have already read data in the expired snapshot (as specified by the for…

https://github.com/tikv/tikv/issues/13298 这个 issue 链接的标题就是 Fair locking，其实就是这个 https://github.com/pingcap/tidb/issues/42107 这个是重命名的 issue https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_pessimistic_txn_fair_locking-从-v700-版本开始引入 这个是系统变量的配置，已经改了名字叫 Fair Locking 那个图片是 tidb 配套的设计： h…

我想问的是悲观锁请求过程中的 lock_only_if_exists 参数哪些场景使用，而不是悲观锁哪些场景使用

感谢回复，也谢谢你分享的分布式锁文档。但是目前我并没有看到关于 Fair Locking 比较细节的文档，特别是关于Fair Locking 的设计文档中 [image] 这个逻辑的描述