ticdc同步上游tidb做从库，下游从库的update qps比上游高非常多倍，而且经常同步延迟

TiDBer_vC2lhR9G · 2026 年7 月 23 日 04:16

【 TiDB 使用环境】生产环境
【 TiDB 版本】上游 8.5.4，下游8.5.7
问题：ticdc同步上游tidb做从库，下游从库的update qps比上游高非常多倍，而且经常同步延迟

上游信息：

下游信息：

第一个图是业务主库，qps update也就1点几k，下游从库直接变成了十几k的update，这是有bug吗，为啥ticdc会回放这么多update语句。

操作路径：我是通过br进行一次全备，然后下载再通过br 恢复备份，然后通过ticdc 把全备后的tso作为起点进行增量实时同步。

zhanggame1 · 2026 年7 月 23 日 06:04

正常的，上游一个update改1万行，下游就是1万个update

Billmay表妹 · 2026 年7 月 23 日 06:07

你用新 ticdc 架构了吗

TiDBer_vC2lhR9G · 2026 年7 月 23 日 06:25

怎么算新，我源端是v8.5.4

TiDBer_vC2lhR9G · 2026 年7 月 23 日 06:27

不至于吧，这是为啥，为啥要补全拆成单独行执行，这样下游压力无限制放大

Soysauce520 · 2026 年7 月 23 日 07:09

防止大事务，cdc压力会小

纯白镇的小智 · 2026 年7 月 23 日 08:33

业务每几秒无脑刷新 update_time，大量无业务意义的变更，同步流量暴增。

TiDBer_vC2lhR9G · 2026 年7 月 23 日 08:50

那为啥源端的update qps这么低

TiDBer_AHjy0eKV · 2026 年7 月 23 日 22:59

由 TiDB 底层的存储机制 以及TiCDC 的同步原理 共同导致的

kang · 2026 年7 月 24 日 00:30

这个问题我遇到过，大概率是CDC同步时把INSERT和DELETE也转成了UPDATE导致的。检查一下下游表是否有主键或唯一索引，如果没有，CDC会使用所有列作为匹配条件，导致每条数据变更都变成UPDATE。

独善其身 · 2026 年7 月 24 日 01:15

TiDB 上层 SQL：UPDATE t SET col=xx WHERE create_time >= xxx;

上游视角：1 条 SQL、1 次 Update QPS，不管命中 1000 行还是 10000 行，数据库慢日志 / 监控只统计 1 次 SQL 执行；
TiCDC 底层：读取 TiKV Raft 变更日志，只认识「单行 KV 变更」，匹配多少行就生成多少条 Update 行事件，下游回放就是对应条数的 Update SQL。
主键 / 唯一索引被 Update 修改 → CDC 强制拆成 DELETE + INSERT，下游两条写入，QPS 直接翻倍

版本规则：v6.5.10 /v7.1.6 之后，MySQL/TiDB Sink 场景，只要更新主键、唯一索引字段，TiCDC 不再生成标准 UPDATE，强制拆解为 DELETE + INSERT 两条变更事件回放TiDB。

普通字段更新：1 行变更 = 1 条 Update
主键更新：1 行变更 = Delete + Insert（下游监控两个写入指标同步暴涨）你的监控只统计 Update 指标，Delete 不计入，大量主键更新场景，单纯 Update 数值不会体现翻倍，但普通字段批量更新就会纯 Update 数量暴增。

system · 2026 年7 月 31 日 03:34

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