我们有一个场景，一条update语句更新3000行（update tablename set x='xxx' where id>0 and id <3001），然后提交。发现canal收集速度明显慢于正常情况。

从mysql中查看binlog，发现一个事务里，分成了47个update_row event（因此一个update_row event包含64个行变化）， 在我们的消费场景中消费时发现一个entry（rowDatas）中有64个BinlogRow。47*64正好对应3000行变化。

做了一些测试，发现当所更新的mysql行的大小比较小的时候，一条语句更新多行时，会有这种情况，收集速度也很慢。
但是mysql行比较大的时候，（更新3000行，binlog原始文件中有3000个update_row event），这个时候收集速度就正常了。

现在想了解：
1.是否是因为更新多行产生的binlog内容（一个entry包含多个行变化信息）导致 后续解析速度慢，从而收集速度变慢
2.具体什么情况下，一个update_row event会包含多个行变化
3.针对一条sql语句更新多行的场景，有没有办法提高处理性能