那个region 有属于 上面的 分析的表不 ？？ 那个时间段
我现在资源不是瓶颈
没有，现在表就晚上凌晨低峰分析
这好像是6.5.1的bug 在修了
从你的日志来看，应该是region找不到或者region leader找不到。
参考原理来看，正常的region做merge或者分割都可能。所以你考虑一下是不是有同时大量的序列写入或删除导致region的分割和归并工作太多。
如果是顺序写入，应该属于正常，如果是离散写入，应该稍微有点不正常。从目前来看，不算问题。
你有升级到6.5.1吗
写入的量不算大还好，我最大写入是一个分区表，按照时间range分区的，还把时间字段加了索引，业务特征使然
这个问题应该很多人都碰到过。资源占用不多，理论上没有这个问题的。
这个报警的可以参考官网 https://docs.pingcap.com/zh/tidb/v6.1/alert-rules#tidb_tikvclient_backoff_seconds_count
TiDB 访问 TiKV 发生错误时发起重试的次数。如果在 10 分钟之内重试次数多于 10 次，则报警。这个还是要看发生重试的类型是哪种
可以在 overview 面板中 —> KV Backoff OPS 中，可在下面加个表达式看看具体是哪个指标触发的。
increase(tidb_tikvclient_backoff_seconds_count[10m]) > 10
之前有遇到过是因为锁的原因导致重试请求，tikv日志里面会有比较多的锁等待的相关日志，最后优化业务逻辑解决，可以参考下
已经报出来了，有错误原因
这个错误频繁的报警让人头疼
其实我的写入并不大
知道指标了又咋样尼？无法解决，为什么会不断重试尼
我的业务是按照时间分区，并且时间加索引，这个不太好调整的。因为要按照时间排序
大佬们，按照时间排序的就没有什么好的办法解决吗
兄弟，告警解决了吗