看了下参数，可能是 tidb_audit_log_redacted 参数，控制是否审计日志是否脱敏 审计日志是企业版本功能，建议找原厂售后支持

看下操作系统日志有啥东西没 可以登录到目标 tikv 节点，先停止服务拉起 systemctl stop tikv-20160.service，然后去到部署目录下，找下有个启动脚本，手工运行试试

是的，TiCDC 当前的部署架构中，就是属于上游的的组件 A → B 则需要用 tiup 在 A 集群中扩容 TiCDC 节点 反过来 B → A 则需要用 tiup 在 B 集群中扩容 TiCDC 节点

主机层面的问题，找主机啊 部署在云平台上就去找云厂商

看下 tikv 日志目录下 stderr.log 有东西吗

无感分片不侵入业务、横向扩展避免算力不足、存算分离扩缩容灵活、分布式数据库的高可用能力、超大容量避免存不下、高度 mysql 兼容减少学习和迁移成本 让业务开发专注于业务

一般意义不大，因为数据默认就是分散在所有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