大表以及写热点的问题后期得逐步优化一下。
但是告警规则在两个版本中有了较大的区别：
v3.0.3 >> increase( tidb_tikvclient_backoff_count[10m] ) > 10
v3.0.5 >> increase( tidb_tikvclient_backoff_total[10m] ) > 10
嗯 ， 3.0.5 这种计算方式比 3.0.3 计算出来的值是会大一些的。
我把监控规则调整到v3.0.3版本的计算方式了，告警几乎没有了，不然大批量的频繁告警实在是影响判断。
我这边也有一个类似的告警持续在告警，看起来应该是有写冲突？还请帮忙看看，谢谢。
告警规则：
expr: increase( tidb_tikvclient_backoff_seconds_count[10m] ) > 10
告警内容
kitv相关监控截图
tidb 写冲突日志：
[adapter.go:604] [“pessimistic write conflict, retry statement”] [conn=235107] [txn=418400760041570306] [forUpdateTS=418400760041570306] [err=“[kv:9007]Write conflict, txnStartTS=418400760041570306, conflictStartTS=418400759622139908, conflictCommitTS=418400760041570305, key={tableID=11552, indexID=2, indexValues={53cb1de3e5a6462f9e4d886a9c913449, }} primary={tableID=11552, indexID=2, indexValues={f969cc464c0a4f20bce3759864174fc6, }} [try again later]”]
请重新开帖子，描述下问题和版本，我们跟进一下，感谢配合
您好，想请教下关于读写冲突。我们线上系统最近也遇到了大量的tikvLockFast报错，这里的读写冲突我不是太理解，看您回复的意思是在读的表其他操作在修改，读会被阻塞这个意思？mysql里的读写冲突指的是A事务读的数据被B事务修改后A事务再次读该数据会产生不可重复读异常吧？我们的业务系统里读都没有在事务里额，不在事务里的读应该不会被阻塞？目前不太理解如何产生的读写冲突；或者是update操作有读的步骤这里产生的读写冲突吗？
请重新开帖子，描述下问题和版本，我们跟进一下，感谢配合
在理解读写冲突之前，建议阅读一下官方网站提供的读写冲突的排查文档，非常好用。https://docs.pingcap.com/zh/tidb/stable/troubleshoot-write-conflicts
好的，我重新发帖看看，不过你给的这个链接好像是写写冲突，我遇到的问题是读写冲突，tikvLockFast这个异常比较多，然后不太理解为什么读会被写的锁给影响
，感谢配合
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。