在MySQL5.7 引入基于Logical clock的并行复制方案前，MySQL使用基于Schema的并行复制，使不同db下的DML操作可以在备库并发回放。在优化后，可以做到不同表table下并发。但是如果业务在Master端高并发写入一个库（或者优化后的表），那么slave端就会出现较大的延迟。基于schema的并行复制，Slave作为只读实例提供读取功能时候可以保证同schema下事务的因果序（Causal Consistency，本文讨论Consistency的时候均假设Slave端为只读），而无法保证不同schema间的。例如当业务关注事务执行先后顺序时候，在Master端db1写入T1，收到T1返回后，才在db2执行T2。但在Slave端可能先读取到T2的数据，才读取到T1的数据。
MySQL 5.7的LOGICAL CLOCK并行复制，解除了schema的限制，使得在主库对一个db或一张表并发执行的事务到slave端也可以并行执行。Logical Clock并行复制的实现，最初是Commit-Parent-Based方式，同一个commit parent的事务可以并发执行。但这种方式会存在可以保证没有冲突的事务不可以并发，事务一定要等到前一个commit parent group的事务全部回放完才能执行。后面优化为Lock-Based方式，做到只要事务和当前执行事务的Lock Interval都存在重叠，即保证了Master端没有锁冲突，就可以在Slave端并发执行。LOGICAL CLOCK可以保证非并发执行事务，即当一个事务T1执行完后另一个事务T2再开始执行场景下的Causal Consistency。