MySQL 5.1开始支持基于行的复制，这种方式会将实际数据记录在二进制日志中，跟其他数据库的实现比较相像。它有其自身的一些优点和缺点。最大的好处是可以正确地复制每一行。一些语句可以被更加有效地复制。

        基于行的复制没有向后兼容性，和MySQL 5.1一起发布的mysqlbinlog工具可以读取基于行的复制的事件格式(它对人是不可读的，但MySQL可以解释)，但是早期版本的mysqlbinlog无法识别这类事件，在遇到错误时会退出。

由于无须重放更新主库数据的查询，使用基于行的复制模式能够更高效地复制数据。重放一些查询的代价可能会很高。例如，下面有一个查询将数据从一个 大表中汇总到小表:

mysql> INSERT INTO summary_ _table(col1, co12，sum col3)

-> SELECT col1, col2, sum(col3)

-> FROM enormous_ table

-> GROUP BY col1, col2;

        想象一下，如果表enormous_ table 的列coll和col2有三种组合，这个查询可能在源表上扫描多次，但最终只在目标表上产生三行数据。但使用基于行的复制方式，在备库上开销会小很多。这种情况下，基于行的复制模式更加高效。

但在另一方面，下面这条语句使用基于语句的复制方式代价会小很多:

mysql> UPDATE enormous table SET col1 = 0;

        由于这条语句做了全表更新，使用基于行的复制开销会很大，因为每一行的数据都会被记录到二进制日志中，这使得二进制日志事件非常庞大。并且会给主库上记录日志和复制增加额外的负载，更慢的日志记录则会降低并发度。

        于没有哪种模式对所有情况都是完美的，MySQL能够在这两种复制模式间动态切换。默认情况下使用的是基于语句的复制方式，但如果发现语句无法被正确地复制，就切换到基于行的复制模式。还可以根据需要来设置会话级别的变量binlog_ format, 控制二进制日志格式。

        对于基于行的复制模式，很难进行时间点恢复，但这并非不可能。稍后讲到的日志服务器对此会有帮助。