是 golang 1.22 废弃了 TLS 1.0 的支持，而一些老的 MySQL 5.7 的镜像使用的是比较早的 Debian 版本，上面的 TLS 版本很低。 解决办法要么是重新用 1.21 手动编译一下 dumpling，要么就是用老版本的 dumpling，dumpling 是没有类似 --ssl-mode=DISABLED 参数的

在进行 analyze 时候，也可能会导致 TiKV IO 和 CPU 高的，所以还是执行一下 show analyze status; 看下当时有没有 analyze

感觉 k8s + TiDB 的优势是运维简单，TiDB 计算节点的扩缩容可以用到 k8s HPA 的能力。缺点也很明显，如果 TiKV 用网络盘性能会很差，如果用本地盘，TiKV 的扩缩容和本地 TiUP 部署对比就没什么优势了，反而多了 k8s 的运维复杂度。

可以看下 auto_analyze 的时间配置，是不是自动对这个分区表的Global stats 做了analyze

大概率是统计信息的问题，EXCANGE PARTITION 后统计信息需要重新生成的。

我给挪到BUG 反馈板块吧

是的，在节点个数多了后，这个 ng-monitor 采集的 TOP SQL 数据量就很庞大，出现过几次把监控节点内存搞满的情况了。。。

我也遇到过这种问题，最终操作方法也是删除 tsdb 解决的。我建议别关单，这种还是 ng-monitoring-server 的 BUG 导致的，还是需要修复的

[image] 不过貌似 mixed 的级联删除，也是会被记录成 ROW 格式的，那就太奇怪了。。。

上游 MySQL8的 binlog 格式是什么？ 是row 还是mixed 啊？

你的 DM 任务没有同步子表么？ MySQL的 row 格式保证即便是通过外键约束删除的子表，这个删除也会产生 DELETE 类型的 BINLOG EVENT 的

检查原始文件的数据有没有重复的吧，这个是概率最大的

你这种情况大概率是主表，和索引里的数据不一致导致的，用admin check table应该会报错。 题主的问题还不太一样，主键查询就出现问题了，执行索引看起来也没什么问题

可以看下官方文档的原理：因为 TiKV 底层是个 KV 存储，在构成键值对时候，同一个 key 对应的记录天然会被合并成一条。 [image] 可以根据冲突检测， 来看下是否符合预期。其实 local 模式导入新表报错，十有八九就是文件中的数据有重复，或者格式不对导致的 https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-physical-import-mode-usage/#冲突数据检测

表已经要设置一个主键，如果都没主键，数据重复了，都发现不了

看下是否是文件中存在冗余数据？ tidb-lightning 的 local 模式会先对所有数据做排序转写成 SST 文件，很可能会将冗余数据汇总成一条

使用 admin check table 看下表是否有损坏吧

下个十年见！

交给 AI 来处理，让它给你拼 SQL