一般意义不大，因为数据默认就是分散在所有tikv机器的，每个节点都是既有 leader，既有follower的 只有在那种多中心部署架构，然后某中心又全是follower的时候，这种情况可以读取本中心的follower副本数据，避免产生大量的跨中心流量

先看慢查询日志，这块有执行计划，会显示每个算子执行效率

充电器头非常好用

能问下这是什么业务吗，1 天就有 8000w 的数据，这种量挺大了，并且列 100+，证明业务很复杂啊

你做的离线镜像不包含 localinstall.sh 的，这个离线镜像不能执行 localinstall.sh 装tiup，你这个离线镜像只能给 tiup 当离线源用 只有从官网下的离线包里，才有那个 localinstall.sh ，执行后会安装 tiup 工具

单个 key 是无法再 split 的，因为 Region 起止范围只到 key 这块，没有后边的 mvcc 版本号 已升级到 v8.5.3，建议调小 GC 设置，适当调小这些 GC compaction 相关参数的值 https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file/#gcauto-compaction 还有你装 tidb 节点了吗，虽然是 rawkv，但是 tidb 集群 gc 还是要 tidb 节点的，得装一个 tidb 节点

用 tiup 修改就好了，Region 调度是异步的，调整完参数再用 pd-ctl 去确认下

看着像 tikv 有残留锁没有释放 1 因为看着 tikv min resolved ts lag 也是很高

基于服务客户的 【你所在企业的 TiDB 集群规模有多少节点（PD+TiKV+TiDB 的数量）？】 单集群 100+ 【TiDB数据库承载的业务类型？（数据中台/核心交易类/内部办公类/大数据分析类/备库…）】 数据中台/核心交易类/大数据分析类 比较多 【目前你对 TiDB 集群采用的主要数据保护方式是什么？（无保护/BR 脚本备份/ 统一备份软件/ TiCDC 容灾）】 BR 脚本备份/ TiCDC 容灾 【如果有 TiDB 备份一体机，你们企业是否有考虑采购 TiDB 专属备份一体机？有需求吗？大概的预算是多少？】 至少这个产品能备份很多种数据，并且操作简单化，效率高，…

https://github.com/pingcap/tidb/pull/37800 cte 只被引用一次，会被自动 inline，这是从 v6.4 引入的 cte 相关的改动在 v6.5 版本也比较多，具体不知道那个导致你这种情况的，猜测可能跟这个有关 https://github.com/pingcap/tidb/issues/55881 [image] 建议你还是从应用去修改下 SQL 绕过吧

那也没见 CTE 里就写一个标量的，一般 CTE 里都是有一定逻辑的

所以你为啥要这么写呢？

比较奇怪的一点是看不到 SQL 文本，不过通过执行计划可以看到访问的是 stats_histroy 表，这块有个历史统计信息功能有问题，高版本已经是默认关闭了，v8.1.0 默认是打开的，关闭就好了，这个参数关了就好了 tidb_enable_historical_stats

具体是什么告警，告警表达式是啥？

怎么装的，不会是 palyground 吧，那个默认是监听在 127.0.0.1 的

去删一删无用的 日志什么的吧，还有 space_placeholder_file 文件也可以删除 还有你没监控的吗？为告警的的吗

看下是不是这问题 resourcemanager: slot token limit can be too low when the ru request rate is not even · Issue #9605 · tikv/pd · GitHub

发下监控啊，还有可以设置让 RG 超用的

24h