是的，发现负载高期间，有其他服务的全表扫描； 目前排查replace into（百万级数据量）和全表扫描资源争抢；符合大佬给出的问题处理思路； 额外问题：对于每天都有大量（百万级）数据replace into 有啥建议？ (也是回归主题，能否减少replace into带来的负载高问题。) ps：研发刚接手此服务，还在跟研发要SQL和场景

8c 64G，单实例部署

192.168.209.5:22379文件系统坏了？ 是如何操作的呢？ 比如：扩容、缩容，需要详细描述下。

storage.block-cache.capacity 参数设置的多少，实例总内存多少。 可用信息太少了

重建表

期待～ 学习ing

8.1 LTS加 udf么

点赞 ，很及时！ 我们还真有这个使用场景

顶，这需求有必要啊

get！

如果 同时配置了2个参数： memory-usage-limit < storage.block-cache.capacity 5/3 那么 真实的 memory-usage-limit=storage.block-cache.capacity5/3吗

独立部署

我也这么理解 ，但是memory-usage-limit没限制住。

部分帖子说memory-usage-limit= storage.block-cache.capacity *0.75/0.45

历史帖子关于限制TiKV实例内存使用的参数都有哪些？ - #2，来自 ethercflow

我这也这样。 总内存64G、memory-usage-limit=52G、storage.block-cache=38G，有出现OOM问题，而且多个TiKV内存到达59G

还有一点，tiproxy能否在资源不足时，限流部分昂贵查询

tiproxy能根据tidb-server的资源消耗情况，智能路由到资源消耗少的节点？

冲锋衣已兑换，材料很好的。