手动delete数据，会导致ticdc delay问题，这个具体是什么逻辑我还是没太明白，哪个老师帮我解释一下呀

🪐 TiDB 技术问题
1

如题，基础太弱也没时间好好看文档，求老师讲解，谢谢~

我想弄明白原理

2

很简单啊，delete SQL会作用到 tikv，ticdc 会捕获 tikv 数据变动的事件

如果 delete row 特别多，比如 50W 行，比较常见了
那ticdc 也会回放 50W 行event到下游， 这个时候会出现两个问题：

  1. ticdc changefeed 设定的资源是否足够处理这个量级
  2. ticdc 下游对接的服务，是否有足够的资源处理这个量级

ok，处理不了，ticdc 就会 delay 了…

3

只是因为ticdc节点处理能力不足引起的吗？
跟gc compact这些有关系吗？

4

你一个事务处理数据量太大，其他事务不是会等待吗，要是上游有这操作也会导致dm同步延迟或者同步异常

5

gc or compact 的操作是针对 tikv 的…

然后不论 是 GC，还是 compact 都会占用 tikv 的资源

至于大事务的问题，也应该考虑进去… 这玩意会吃很多内存… :see_no_evil:

新版本对大事务好像有一些优化，能够分批执行，我忘记哪个版本了

6

好的 感谢

7

delete是DML命令，如果删除整个表，还是用drop这种DDL命令快一些。

8

同问.

9

truncate table 会更快了
drop 是连表都删掉了，不一样的…

10

truncate的话cdc是不是只有一条truncate命令，没有其他数据下发

11

批量删除历史数据确实是个头大问题，如果用分区表，又会有超长时间ANALYZE头疼问题：

12

删除可以一天删一点最合理

13

解释的到位！

14

的确，DDL相比DML，删除数据要快。

15

这个确实很头疼，分区表可以解决大批量删除历史数据的问题，但是分区表又有本身的一些问题，比较不好权衡。

16

每天增量导入数据后,批量删除一部分这意思吗

17

对，慢慢来对集群稳定性影响小

19

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。