如果确认未来数据一直是以 同步方式向 TIDB 写入数据，可以考虑把 AUTO_INCREMENT 属性去掉，并且将主键改成 member_id ,integral_type, id ，并且删除 member_id ,integral_type 这个 二级索引 好处是利用业务 member_id 的离散型来打散数据。 但注意数据查询需要 id 进行过滤时候，尽量将其他二级索引改成 tran_id+id 等等来加速查询效果减少回表带来的 时延

同时 你用 tiup ctl:v5.2.1 pd 查看下单peer 的 region 数量 https://docs.pingcap.com/zh/tidb/stable/pd-control#根据副本数过滤-region 可将结果以附件形式发出来

先安装最新版本的 clinic 然后上传相关日志看下问题 https://docs.pingcap.com/zh/tidb/stable/quick-start-with-clinic 上传好之后可以将 地址私信给我

cop没有 超时 但有 excute time out session 变量和hint 可以控制sql 超时

在分区剪裁规则优化前，是没有的。 正常 6.3 会发布 ，但会争取 6.1.1 合入。预计 9月中前会发出

从你之前的帖子来看 是因为 TOP 下推到了 全部 partition [image] 从 执行计划看 task 任务最长 45s task 数量 11228 。并且看你的 Placement rule 有 冷热之分。所以 整体查询任务会非常慢，逻辑上是预期内的 最直接有效优化建议强制 使用分区裁剪 譬如 增加 where dt > ‘2022-06-01 00:00:00’

你这单机部署单机 prepare 想来 CPU 线程切换应该很频繁。估计资源都消耗在线程切换调度上了。

我看你采用的local file 的方式进行数据恢复的 这里需要你确认 BR 应用可以正常访问到 、tmp/br_backup 目录和数据 所有、所有、所有 tikv 节点可以正确 访问到 tmp/br_backup 目录和数据 如果 tmp/br_backup 为 NFS 远程映射。搜索BR 备份日志中， “download file failed” 这个关键字，找到对应 SST 文件 ，确认远程目录中文件大小是否存在异常，也可登录到 tikv 服务器上远程连接检查文件是否正常。 最后建议排查下 NFS 服务器是否有相关错误日志。

看了下 BR 的代码 先说结论大概率是你的 Ceph 版本太低了和 aws 的s3 包不兼容了 https://github.com/pingcap/br/blob/v5.0.6/pkg/storage/s3.go [image] BR 里面的 S3 接口引用的 Aws 官方的。

看这个 执行信息 应该是你 GC 时间设置的问题。 GC 时间过长，但相关数据更新修改频繁导致 processkey 1750 total key 是真实数据的 几千倍。 GC 调整后 可以再看下执行情况。

理论上超过 30min 的 B 节点上的相关数据已经无意义了。此时加入其实相当于将 region peer 重新进行回迁 更加高效的解决办法 tiup --force 强制缩容 B node 手动在 B Node 进行数据和服务清理，同时检查是否有残留进程 node export、 blackbox 、tikv server 将 B 节点重新扩容回集群

内存异常 往往 进程会出现非预期的假死情况。 嗯 tiflash 同步数据是通过 复制 raft peer 来完成的。如果进程卡主后续工作都会有影响

tiflash 上的 raft peer 为 learner 代表从 tikv node 上相关 raft leader 向 tiflash 进行 raft sync unreachable to 代表 sync 失败 full to 代表 leader 发生切换后向 tiflash sync 失败的数量

506 已修复 相关 issue 与 pr https://github.com/pingcap/tidb/issues/24095 https://github.com/pingcap/tidb/pull/24102

SQL SELECT t.id priceOperationId, t.main_type mainType, t.operate_type operateType, t.price_id priceId, t.hotel_id hotelId, t.roomtype_id roomTypeId, t.rateplan_id ratePlanId, t.begin_date beginDate, t.end_date endDate, t.rateplan_code ratePlanCode, t.gen_salecost genSaleCost, t.gen_saleprice genSa…

参考这里排查下

所以你的意思是你使用的是自己修改的 start_run 脚本来启动 dm-worker 报错了？ 建议你先试试官方的启动脚本是否有问题。如无问题按照你截图信息来看 是你的 cpunode 和你绑定的编号越界导致的。先确认下 cpuinfo 再仔细调试自己的 脚本

多不多 可以自己计算下 (行数+索引数量）* top_n* 分区数量 top_N 默认 20 最大 1024

你用 tiup cluaster edit-config 可以展示目前完整的部署信息