上游数据库mysql 5.7 下游tidb 版本v6.5.0 迁移工具使用DM, 且上游数据有主键和自增，因为tidb迁移时，需要上游mysql的行格式为row格式，所以将原来mysql的格式有mixd 转成row格式了，但是迁移完以后，同一个表，tidb的总行数比mysql的多，请问这个是什么原因？
怎么统计的表的行数
是静态表还是动态表，是否有持续写入，可以先创建测试静态表，观察是否正常
下游比上游多？上游有删除操作没有迁移成功么？
就是count(1) 统计的总行数
动态表，但是再一段时间内是没有写入的，静态表有几个行数是一致的
下游比上游多，上游没有删除操作，静态的表同步没啥问题
那就奇怪了。迁移前下游表里是空的么？
行数多你要比对一下数据是怎么多了？多的是否正常，还是说原来MYSQL的统计行数不准确
迁移前下游就没有创建库和表
下游有没有控制dml权限
都是用的count(1) 统计的，不知道为什么行数会多，但是看最开始的第一个数据，和最后一个数据能对上。mysql的行格式是 这个 Dynamic tidb的行格式 是Compact 不知道是不是这个原因
给的是全部权限
除了迁移用户，其他用户也有写入权限吗？
就是用的root用户
嗯嗯，但是我现在是全量加增量的同步过程中，不能用这个工具，只是我看mysql的数据没有增加了，但是tidb的总行数比mysql的多，就是感觉有些奇怪
mysql侧有不懈binlog的操作做吗，有个会话变量可以控制
什么一些？是dm中的过滤操纵吗？dm同步时只有一个指定同步一个库的操作，其他操作没有
你现在不是下游比上游数据多吗，数据不一致，如果你DM没有特殊配置的话，有没有可能上游部分操作没有写binlog，导致下游没有，mysql有个变量可以让会话级别不写binlog，会不会有人用这个操作了数据库，https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_sql_log_bin