Ryan-Git

那就比较奇怪了，确认下源端为啥执行慢？预期执行的 sql 应该是`select * from xx where id > xxx limit 10000`，不应该花 4~5 秒。 不是，是调低`input.config.table-scan-batch `，调高`input.config.batch-per-second-limit`。

哦。。。那就不是同步的问题了。类似`mysql`自身的主从延迟，大事务是在`commit`时候才刷`binlog`的，这期间`gravity`也没法同步。

1、可以看下具体场景 2、datax 我记得是扫表的，不是走的 binlog，自然没有这个问题。有条件可以跟 canal 或者 mysql 自身的主从比较一下，或者让 gravity 直接输出 binlog 看看。

唯一索引需要额外判断冲突，是会慢一点。但慢这么多确实不符合预期，我看下。

我在`MySQL`上试了一下上面提供的例子，几乎没有差别。你也试试？ 这样的话看下目标侧为什么慢？前几年唯一索引`TiDB`似乎有锁冲突比较严重的问题，现在不太清楚情况。

看起来关系不大，截图的监控是阻塞在目标端。可以直接看`output`延迟相关的指标。

具体怎么丢失？直接写 mysql 应该没问题的。 序列化的话 json 本来就没有 decimal

有没有完整的堆栈，这个只有一行-。-

@selectliu 你手动进容器看看日志，这个 ELK 应该没把多行日志导出来。

@selectliu 再试一下。 其实应该在pr分支测的，有问题这个issue再打开吧。