告警大量的tidb_tikvclient_backoff_seconds_count

[jeff (Hacker Ix S2 Eg3x)]

【 TiDB 使用环境】生产环境
【 TiDB 版本】 4.0.13
【遇到的问题：问题现象及影响】
告警大量的 tidb_tikvclient_backoff_seconds_count 告警，看tidb日志中大量的Write conflict。 大佬有解决的办法吗？ 另外日志中的tableid 299，怎么能对应找到表名？
【附件：截图/日志/监控】

[undefined]

乐观模式？

[jeff (Hacker Ix S2 Eg3x)]

pessimistic

[tidb狂热爱好者]

这个是慢sql导致的

[jeff (Hacker Ix S2 Eg3x)]

如何根据tableid 号，找到表名？

[h5n1]

https://docs.pingcap.com/zh/tidb/stable/troubleshoot-lock-conflicts#tidb-锁冲突问题处理

[啦啦啦啦啦]

和慢sql无关

[裤衩儿飞上天]

select TIDB_TABLE_ID,TABLE_SCHEMA,TABLE_NAME from INFORMATION_SCHEMA.TABLES where TIDB_TABLE_ID=XXXXX;

[啦啦啦啦啦]

访问 TiKV 发生错误时发起重试的次数，这个报错如果不是特别多可以忽略，或者把阈值调大点。
INFORMATION_SCHEMA.TABLES里有table id

[jeff (Hacker Ix S2 Eg3x)]

总是在报，每次200左右

[啦啦啦啦啦]

是不是有批量操作导致region频繁变动，我们是把warning忽略的，只发error的告警，一般来说这个warning对业务没影响

[像风一样的男子]

有一阵我这也很频繁出这个warning，后来升级kv配置就没了

[jeff (Hacker Ix S2 Eg3x)]

看文档 这个是正常的呗。就是并发量太大了

[redgame (Ti D Ber Pa Amoi Ul)]

试试改tikv-client.commit-timeout 参数的值，例如将其从默认值 调整为更大的值，如 120s。这样可以增加提交事务的超时时间

[undefined]

一般这种情况 热点图上肯定能见到这张表，读写量应该都挺大，考虑下业务拆分