我们已经讨论了这两种复制模式的优点和缺点，那么在实际应用中哪种方式更优呢?理论上基于行的复制模式整体上更优，并且在实际应用中也适用于大多数场景。但这种方式太新了以至于没有将一些特殊的功能加入到其中来满足数据库管理员的操作需求。因此一些人直到现在还没有开始使用。以下详细地阐述两种方式的优点和缺点，以帮助你决定哪种方式更合适。

基于语句的复制模式的优点

        当主备的模式不同时，逻辑制能够在多种情况下工作。例如，在主备上的表的定义不同但数据类型相兼容、列的顺序不同等情况。这样就很容易先在备库上修改shena,然后将共提升为主库，减少停机时间。 基于语句的复制方式般允许更灵活的操作。基于语白的方式执行复制的过程基本上就是执行SQL语句。这唐味着所有在服务器上发生的变更都以一种容易理解的方式运行。这样当出现问题时可以很好地去定位。

基于语句的复制模式的缺点

        很多情况下通过基于语句的模式无法正确复制，几乎每一个安装的备库都会至少碰到一次。事实上对于存储过程，触发器以及其他的一些语句的复制在5.0和5.1的一系列版本中存在大量的Bug。这些语句的复制的方式已经被修改了很多次，以使其更好地工作。简单地说:如果正在使用触发器或者存储过程，就不要使用基于语句的复制模式，除非能够清楚地确定不会碰到复制问题。

基于行的复制模式的优点

        几乎没有基于行的复制模式无法处理的场景。对于所有的SQL构造、触发器、存储过程等都能正确执行。只是当你试图做些诸如在备库修改表的schema这样的事情时才可能导致复制失败。

        这种方式同样可能减少锁的使用，因为它并不要求这种强串行化是可重复的。基于行的复制模式会记录数据变更，因此在二进制日志中记录的都是实际上在主库上发生了变化的数据。你不需要查看一条语句去猜测它到底修改了哪些数据。在某种程度上，该模式能够更加清楚地知道服务器上发生了哪些更改，并且有一个更好的数据变更记录。另外在一些情况下基于行的二进制日志还会记录发生改变之前的数据，因此这可能有利于某些数据恢复。在很多情况下，由于无须像基于语句的复制那样需要为查询建立执行计划并执行查询，因此基于行的复制占用更少的CPU。

        最后，在某些情况下，基于行的复制能够帮助更快地找到并解决数据不一致的情况。举个例子，如果是使用基于语句的复制模式，在备库更新一个不存在的记录时不会失败，但在基于行的复制模式下则会报错并停止复制。

基于行的复制模式的缺点

        由于语句并没有在日志里记录，因此无法判断执行了哪些SoL,除了需要知道行的变化外，这在很多情况下也很重要(这可能在未来的MysSQL 版本中被修复)。

        使用一种完全不同的方式在备库进行数据变更,而不是执行 SQL。事实上，执行基于行的变化的过程就像一个黑盒子， 你无法知道服务器正在做什么。并且没有很好的文档和解释。因此当出现问题时，可能很难找到问题所在。例如，若备库使用一个效率低下的方式去寻找行记录并更新，你无法观察到这一点。

        如果有多层的复制服务器，并且所有的都被配置成基于行的复制模式，当会话级别的变量@@binlog format 被设置成STATEMENT时，所执行的语句在源服务器上被记录为基于语句的模式，但第一层的备库可能将其记录成行模式，并传递给其他层的备库。也就是说你期望的基于语句的日志在复制拓扑中将会被切换到基于行的模式。基于行的日志无法处理诸如在备库修改表的schema这样的情况，而基于语句的日志可以。

        在某些情况下，例如找不到要修改的行时，基于行的复制可能会导致复制停止，而基于语句的复制则不会。这也可以认为是基于行的复制的一个优点。该行为可以通过slave_ exec mode 来进行配置。这些缺点正在被慢慢解决，但直到写作本书时，它们在大多数生产环境中依然存在。