MySQL Replication 复制可以是基于一条语句 (Statement Level) ，也可以是基于一笔记录 (Row Level)，可以在 MySQL 的设置参数中设定这个复制级别，差异复制级此外配置会影响到 Master 端的 bin-log 日志名目。
Row
日志中会记录成每一行数据被修改的形式，然后在 slave 端再对沟通的数据举办修改。
利益： 在 row 模式下，bin-log 中可以不记录执行的 SQL 语句的上下文相关的信息，仅仅只需要记录那一笔记录被修改了，修改成什么样了。所以 row 的日志内容会很是清楚的记录下每一行数据修改的细节，很是容易领略。并且不会呈现某些特定环境下的存储进程或 function ，以及 trigger 的挪用和触发无法被正确复制的问题。
缺点：在 row 模式下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样大概会发生大量的日志内容，好比有这样一条 update 语句：
1
UPDATE product SET owner_member_id = ‘b’ WHERE owner_member_id = ‘a’
执 行之后，日志中记录的不是这条 update 语句所对应的事件 (MySQL 以事件的形式来记录 bin-log 日志) ，而是这条语句所更新的每一笔记录的变革环境，这样就记录成许多笔记录被更新的许多个事件。自然，bin-log 日志的量就会很大。尤其是当执行 alter table 之类的语句的时候，发生的日志量是惊人的。因为 MySQL 对付 alter table 之类的表布局改观语句的处理惩罚方法是整个表的每一笔记录都需要变换，实际上就是重建了整个表。那么该表的每一笔记录城市被记录到日志中。
Statement
每一条会修改数据的 SQL 城市记录到 master 的 bin-log 中。slave 在复制的时候 SQL 历程会理会成和本来 master 端执行过的沟通的 SQL 再次执行。
利益：在 statement 模式下，首先就是办理了 row 模式的缺点，不需要记录每一行数据的变革，淘汰了 bin-log 日志量，节减 I/O 以及存储资源，提高机能。因为他只需要记录在 master 上所执行的语句的细节，以及执行语句时候的上下文的信息。
缺点： 在 statement 模式下，由于他是记录的执行语句，所以，为了让这些语句在 slave 端也能正确执行，那么他还必需记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以担保所有语句在 slave 端杯执行的时候可以或许获得和在 master 端执行时候沟通的功效。别的就是，由于 MySQL 此刻成长较量快，许多的新成果不绝的插手，使 MySQL 的复制碰着了不小的挑战，自然复制的时候涉及到越巨大的内容，bug 也就越容易呈现。在 statement 中，今朝已经发明的就有不少环境会造成 MySQL 的复制呈现问题，主要是修改数据的时候利用了某些特定的函数可能成果的时候会呈现，好比：sleep() 函数在有些版本中就不能被正确复制，在存储进程中利用了 last_insert_id() 函数，大概会使 slave 和 master 上获得纷歧致的 id 等等。由于 row 是基于每一行来记录的变革，所以不会呈现雷同的问题。
Mixed
从 官方文档中看到，之前的 MySQL 一直都只有基于 statement 的复制模式，直到 5.1.5 版本的 MySQL 才开始支持 row 复制。从 5.0 开始，MySQL 的复制已包办理了大量老版本中呈现的无法正确复制的问题。可是由于存储进程的呈现，给 MySQL Replication 又带来了更大的新挑战。别的，看到官方文档说，从 5.1.8 版本开始，MySQL 提供了除 Statement 和 Row 之外的第三种复制模式：Mixed，实际上就是前两种模式的团结。在 Mixed 模式下，MySQL 会按照执行的每一条详细的 SQL 语句来区分看待记录的日志形式，也就是在 statement 和 row 之间选择一种。新版本中的 statment 照旧和以前一样，仅仅记录执行的语句。而新版本的 MySQL 中对 row 模式也被做了优化，并不是所有的修改城市以 row 模式来记录，好比碰着表布局改观的时候就会以 statement 模式来记录，假如 SQL 语句确实就是 update 可能 delete 等修改数据的语句，那么照旧会记录所有行的改观。
其他参考信息