版本5.3.0
tidb 查询语句会触发resolveLock操作吗,目前发现很多慢查询中resolvelock占了很长时间
查询语句本身不会触发resolveLock
操作, 如果发现resolveLock
在慢查询中占用了很长时间,可能是应用程序中有某些查询被阻塞,导致锁等待时间较长,需要从其他地方查找原因。
-
ResolveLock:{num_rpc:1, total_time:12.117495ms}
:读数据遇到锁后,进行 resolve lock 的时间。一般在读写冲突的场景下会出现。
当在事务中读数据或者 prewrite
keys 时,如果 key 上已经有 Lock 了,这时就需要进行 ResolveLock
。为什么会出现这种情况?有以下几种情况:
- 事务 txn_1 在完成
prewrite
key_1,key_2 后就异常退出了,那么此时事务 txn_2 再去读 key_1, key_2 时,就会发现有 txn_1 在prewrite
时写的 Lock。 - 事务 txn_1 在
prewrite
key_1完成,但在 key_2 因为冲突而失败时,txn_1 会终止并异步清理 key_1 上的锁,如果异步清理锁还没完成,此时 txn_2 去读 key_1 ,也会遇到 Lock - 事务 txn_1 在
commit
primary key 成功后,是用异步commit
second keys,在异步commit
还没完成时,txn_2 去读 second keys 时也会遇到 Lock。
那么如何 ResolveLocks
呢?prewrite
keys 时会同时带上一个 LockTTL
, ResolveLock
的流程首先是检查所有 Lock 的 TTL,记下最久的 expire Time
,并发现如果有 keys 上的 locks 的 ttl 已经过期后,就会发起对这些过期 keys 的 Locks 进行 resolveLock
,如果还有 keys 的 locks 没有 resolve
,就根据最久的 expire time
进行 back off
后重试。
感谢回复,所以是查询的时候也会进行resolvelock对吧。在写入的时候做resolvelock会不会更好点,当前是snapshot isolation级别.有lock conflict情况下对读的性能不会影响
是的.
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。