单个 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

tidb server 内存使用不高是好事，这是正常的情况 提升tidbserver的内存使用率，还有能提升缓存命中。 一般 tidb server 是不做数据缓存的（除了有个 cop cache），因为 tidb 是分布式的一个架构，tidb server 节点都是无状态的，如果直接缓存数据，一个 tidb 节点更新数据后，还涉及到另一个节点同步的问题， tikv 提供了 block cache 缓存数据

能继续扩容， miss peer 是因为你设置了 tiflash 副本，tiflash 副本还没创建出来，所以它现在认为缺副本，可以通过 pd-ctl 去查看这些 miss peer 的 Region，确认下是不是这种情况。

你 hint 用法不对，写到 select 后边，如果不生效会有 warning

优化 SQL 就好了

需要做 online unsafe recovery 了，有数据丢失了，参考：https://docs.pingcap.com/zh/tidb/stable/online-unsafe-recovery/#online-unsafe-recovery-使用文档 你的集群很奇怪 4 PD、2 TiKV，2 TiKV、2 副本不是正确使用 tidb 的姿势，这个跟 Mysql 不一样