MySQL 的复制可以是基于一条语句（Statement Level），也可以是基于一条记录（Rowlevel），可以在MySQL 的配置参数中设定这个复制级别，不同复制级别的设置会影响到Master 端的Binary Log 记录成不同的形式。
1. Row Level：Binary Log 中会记录成每一行数据被修改的形式，然后在Slave 端再对相同的数据进行修改。
优点：在Row Level 模式下，Binary Log 中可以不记录执行的sql 语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了。所以Row Level 的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程，或function，以及trigger 的调用和触发无法被正确复制的问题。
缺点：Row Level 下，所有的执行的语句当记录到Binary Log 中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容，比如有这样一条update 语句：UPDATE group_message SET group_id = 1 where group_id = 2，执行之后，日志中记录的不是这条update 语句所对应的事件（MySQL 以事件的形式来记录Binary Log 日志），而是这条语句所更新的每一条记录的变化情况，这样就记录成很多条记录被更新的很多个事件。自然，Binary Log 日志的量就会很大。尤其是当执行ALTER TABLE 之类的语句的时候，产生的日志量是惊人的。因为MySQL 对于ALTER TABLE 之类的DDL 变更语句的处理方式是重建整个表的所有数据，也就是说表中的每一条记录都需要变动，那么该表的每一条记录都会被记录到日志中。
2. Statement Level:每一条会修改数据的Query 都会记录到Master 的BinaryLog 中。Slave 在复制的时候SQL 线程会解析成和原来Master 端执行过的相同的Query来再次执行。
优点：Statement Level 下的优点首先就是解决了Row Level 下的缺点，不需要记录每一行数据的变化，减少Binary Log 日志量，节约了IO 成本，提高了性能。因为他只需要记录在Master 上所执行的语句的细节，以及执行语句时候的上下文的信息。
缺点：由于他是记录的执行语句，所以，为了让这些语句在slave 端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端被执行的时候能够得到和在master 端执行时候相同的结果。另外就是，由于MySQL现在发展比较快，很多的新功能不断的加入，使MySQL得复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug 也就越容易出现。在statement level 下，目前已经发现的就有不少情况会造成mysql 的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现，比如：sleep()函数在有些版本中就不能正确复制，在存储过程中使用了last_insert_id()函数，可能会使slave 和master上得到不一致的id 等等。由于row level 是基于每一行来记录的变化，所以不会出现类似的问题。