TIDB7.5有偶发的Lock Resolve OPS及RT99上升

[huixiang]

【 TiDB 使用环境】生产环境
【 TiDB 版本】7.5.3
【遇到的问题：问题现象及影响】
问题： 偶发的Lock Resolve OPS及RT99上升，如何解决？

Lock Resolve OPS突发上升：

RT99上升：

【资源配置】
TIDB7.5 常有偶发Lock Resolve OPS 上升
RT99上升

【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】

[h5n1]

• ResolveLock:{num_rpc:1, total_time:12.117495ms}：读数据遇到锁后，进行 resolve lock 的时间。一般在读写冲突的场景下会出现。

[nobody (不定时出现)]

根据 dashboard 或者 tidb slow 查找 resolve lock 耗时长的 sql 。和业务一起看看是不是符合预期的锁冲突。

[yiduoyunQ]

https://docs.pingcap.com/zh/tidb/stable/troubleshoot-lock-conflicts

• 是否有热数据高并发读写，比如单行热点更新
• 是否有写慢了影响一致性读

[zhanggame1 (Ti D Ber G I13ecx U)]

lock需要应用层查，有不同客户端更新或者删除相同数据了

[春风十里不如你]

检查一下业务逻辑，是否有同时操作相同数据的情况

[小龙虾爱大龙虾 (Minghao Ren)]

从你的图上并不能直接看到 duration 升高与 lock resolve 有关，图中显示的 lock resolv ops 并不是很高啊，才十几，建议先分析对应时间点慢查询

[SONGHX (Ti D Ber P1d V29kt)]

在Dashboard中查日志的关键字“TIME_COP_PROCESS”，看看有没有频繁出现的region_id，再通过region_id去查表名，然后找业务查一查业务逻辑试试。

[Lucien-卢西恩 (路西恩)]

@SONGHX

看看有没有频繁出现的region_id，再通过region_id去查表名，然后找业务查一查业务逻辑试试。

这个方式可以参考一下，另外就是 TiDB 在 Dashboard 里面有相应的 TopN 和 Slow query，可以看看 21:30 到 21:35 之间的 SQL 有没有异常的。