RDS MySQL 优化了并行复制的等待逻辑，有效消除了批量数据处理期间产生的复制延迟。该功能特别适用于在业务低峰期进行批量数据删除、整理、导入等操作的场景。
适用范围
数据库版本：RDS MySQL 8.0
内核小版本：20251130 及以上
开启方式
您可以在主库或只读实例上设置以下全局参数，将 loose_optimize_replica_parallelism 设置为 ON。
参数名称：
loose_optimize_replica_parallelism设置值：
ON生效方式：立即生效，无需重启实例。
优化背景
很多业务会在凌晨或其他低峰期进行数据删除、整理、导入等工作，通常采用小批量多并发的方式进行处理。这种方式处理速度快，并且可以灵活调整批量和并发的大小，控制对数据库的影响。
在执行批量数据处理期间，实例上主要有两种事务：一种是批量数据处理的中等大小事务，一般一个事务内处理几千行数据；另一种是普通业务的小事务。即便在低峰期，实例上还是会有一定量的普通业务。两种事务会交叉存在于binlog文件中，当两个中等事务中间夹着多个小事务，并且这些小事务修改了同行数据时，两个中等事务就无法并发执行了。
如上图所示，Trx2和Trx5是批量数据处理的中等事务；Trx3和Trx4是普通业务的小事务，并且修改了同一行数据。SQL线程在分发这些事务时，Trx2和Trx3都可以正常分发，Trx4则需等待Trx3及之前的所有事务都提交后才能分发；这导致Trx5的分发在Trx2提交后才进行，进而导致Trx2和Trx5无法并行应用。
因此，在批量数据处理期间，从库上并发度非常低，甚至很多时刻只有一个worker在工作，几乎退化成了单线程应用，导致复制延迟问题。
优化效果
以批量数据删除为例进行测试，使用单并发的sysbench write_only脚本来模拟背景小事务，使用8个并发执行数据删除SQL，一个SQL删除5000行数据。只读实例的复制延迟如上图所示，可以看到功能开启前，从库的吞吐很低，复制延迟上升；功能开启后，从库吞吐大幅提升，复制延迟下降最后追平。
实现原理
为了优化这个场景，AliSQL将原本在SQL线程中阻塞后续事务分发的等待逻辑，放到了worker线程中。当有少量修改同行的小事务分布在中等事务之间时，这些小事务会在worker线程中等待依赖的事务提交，而不是在SQL线程中等待并阻塞其他事务的分发。这样，没有冲突的中等事务就能够并发执行了。