我理解楼主的意思是担心即使分布式事务拿到了相同的 commitTs ，但是 primary key 先持久化 commitTs 后就认为事务提交了，其他 key 是一个异步的过程，可能会导致 PiTR miss 掉一部分数据。 这是不会的。因为其他 key 没有持久化 commitTs 之前，其他 key 的记录上会有 startTs 的 lock 记录，PiTR 遇到这种 lock 记录会根据事务状态推进或者删除锁，只有等待锁处理之后才会推进 local checkpointTs。 也就是说即使其他节点的 local checkpointTs 已经推进到了某个 commitTs 10，但…

@TiDBer_ZfRrIo1G 你的表结构可以提供一下排查吗？ 具体复现的 DDL/DML 序列看是否能一起提供下 关注： https://github.com/pingcap/tiflow/issues/4736

@信仰在空中飘扬 https://github.com/pingcap/tiflow/issues/4635 这个 issue 对应的 pr 已经修复了你的问题，是一样的，可以使用新的版本先规避下。 另外： 这个表的 customer_sid 字段是创建表就有的？还是后面 add column 新增？如果是新增的话看是不是能提供下对应的 DDL。 感谢

你的改的 worker-num 应该是有问题的，mounter 线程数控制的是上游 raw kv 的解码并发，不是到下游 mysql 的并发数，具体链接已经回复在下面，可以先暂时重建下 changefeed 或者 update changefeed 配置。

这个问题是 TiCDC 当前行分发规则是按 pk/uk 值不同分发到不同线程导致的。死锁的易出现原因是：TiCDC 为了实现 exactly one 语义将 update 拆成了 delete + replace into，导致 MySQL 在 RC 和 RR 隔离级别下都极易出现重合的 gap lock，导致了死锁。 临时措施： （1）https://docs.pingcap.com/zh/tidb/stable/manage-ticdc/#sink-uri-配置-mysqltidb ，将 Mysql Sink 的 worker-count 调整成1；（会影响并发，不过考虑到本来就有比较…