node export 用的不是 tidb 自带的么？

[image] 这个呢。

看下监控，异常时间这个地方大不大： [image]

试试服务器做一次重启。 然后按照这个文档检查下：https://docs.pingcap.com/zh/tidb/stable/check-before-deployment/，系统配置调整有没有做，比如大页等。 min_free_kbytes 可以调整到 4GB。 tikv 会缓存占用较大内存，但是频繁触发内存碎片话整理是不常见的。

1、统计信息可以收集下看看 2、一般和条件有关，比如一些越界情况或者一些条件下扫出的数据比较多，导致执行计划变化 加 bind 是解决的一种方案。

服务器多大内存的？

调大下 min_free_kbytes 试试： https://docs.pingcap.com/zh/tidb/stable/check-before-deployment/

swap 开了么？

卡的盘上面有部署什么 tidb 相关东西么？如果有，感觉可以考虑换个目录？试试呢

[image] https://docs.pingcap.com/zh/tidb/stable/sql-statement-load-data/#mysql-兼容性 应该是新版本机制变了。而且 tidb_dml_batch_size 失效也会导致不能拆批，导致性能下降

理论上相对准确。最好还是手动收集一遍。 因为统计信息表中的列带 table id，如果上下游表 id 变了，就得重写所有 value 了。 不过 flashback 这个操作看起来并不会重写 table id。理论上看起来没问题。

如果觉得是 tidb-server 侧的问题： 看下 proxy 侧有没有瓶颈 看下应用服务器资源使用率 有个通用优化方案是 tidb-server 多实例部署并且绑核或者绑 numa。会有提升的。

改了 好了？

如果是 truncate table，gc 后会立马回收空间的。 alter table compact 是压 tiflash 的，和 tikv 无关。

我看了下内部 release 计划，8.5.4 才能修复。 TiKV assertion panic related to CDC · Issue #18498 · tikv/tikv · GitHub 这个问题

我看了下内部 release 计划，8.5.4 才能修复。 TiKV assertion panic related to CDC · Issue #18498 · tikv/tikv · GitHub 这个问题

[image] 对应的 cpu 线程有太大么？看起来已经超过默认限制了。

可以一样场景在 MySQL 上测试下，对比下行为反馈下。如果不一样就去 bug 区反馈下即可。

看起来这个项目已经没更新了。