预切分数据，是自己知道数据大概是什么范围，然后去执行 split 语句，而你这种自己想切分 region 的，有个更合适的 api pd-ctl 支持切分 region，不用制定 key，只需要指定 region_id 就行了 operator add split-region 1 --policy=approximate // 将 Region 1 对半拆分成两个 Region，基于粗略估计值 operator add split-region 1 --policy=scan // 将 Region 1 对半拆分成两个 Region，基于精确扫描值

SPLIT TABLE t INDEX idx 语句并没有让你填每个 region 的范围啊，只让你填上下界和 region 数，要测试啥？ SPLIT TABLE table_name [INDEX index_name] BETWEEN (lower_value) AND (upper_value) REGIONS region_num

这里计算 region split 切分后的边界，本来就是自动的啊 问题1: upper 和 lower 的值会先编码成 byte 数组 请问这里如何将upper和lower值编码成byte数组呢？我们怎么计算出这个数组的呢？ 不用算，它是自动的 问题2: lower 和 upper 各取前 8 字节转成 uint64 请问这里如何取值8字节并转成unit64呢？可以使用一个案例说出详细步骤吗？空有文字我们难以脑补。 不用算，这是自动的，代码类似 binary.BigEndian.Uint64(b byte) 问题3: step = (upper - lower…

开 general 日志看吧，或者把慢查询阈值调整为 0

一般没有吧 balance-region-scheduler 关掉的需求，数据倾斜严重就更不应该关了，这个调度就是用来保证各节点数据量差不多的调度

优化 SQL 就好了，初步看你的执行计划中回表比较多呢

是的，因为没有位置放新的副本 符合预期的，pd 认为它缺副本 PD 不会对缺副本的 region 进行 merge 调度，这种 region 应该优先补副本 监控 PD => Scheduler => Region merge checker 会看到相应的指标 应该不会，这种情况是 3 副本剩余 2 副本，还是能正常对外提供服务的 因为你配置错误啊，PD 的 rule checker 是高优先级的，副本数正确才能进行进一步调度 因为 raft 层面它只有 3 副本啊，3 副本全部正常，自然可以对外提供服务

[image] 已转发

朋友们当下你们是否也会遇到这样的困境？ 有 面对资源缺口，你们会倾向于上云吗，还是其他方案？ 倾向于其他方案吧 上云过程中，你最担心的是成本、稳定性，还是迁移风险 ？ 数据安全，稳定性

关键看你要咋用这些数据，光存储肯定是没问题，TiDB 还是做 TP 和 HTAP 好些，纯 AP 不好用，性价比也不高

在 v6 版本做过百亿表的加索引，做了一周多，你这个已经 v8.5 版本了，开 dxf 问题不大，慢慢搞，有问题就暂停 DDL

先解决 tikv 挂掉的问题，3 副本情况挂 2 个就不能用了，去看 tikv 的日志

先看看是不是元数据锁阻塞了 DDL 执行，https://docs.pingcap.com/zh/tidb/stable/metadata-lock/#元数据锁的可观测性

接下来几次分享主题都很棒

看你集群版本是 v8.5.5，不知道你用的 CDC 是老架构还是新架构，建议你用新架构 老架构本身设计上就会有 1S 延迟，调整 cdc.min-ts-interval 可以减少延迟，不过会增加流量，详细参考官方文档 如果用新架构，延迟应该是比老架构要好很多的，你可以测试一下，新架构参考：https://docs.pingcap.com/zh/tidb/stable/ticdc-architecture/

看具体日志 br.log 看有什么报错没有

就在支持的操作系统里选吧

收到了 hangup 信号退出的，把任务放后台跑吧，用 nohup 试试