大多数业务在高峰期会以较高的并发度更新数据库，当主库业务的TPS过高，高于从库IO和SQL线程的吞吐时，就会产生复制延迟。为解决此问题，RDS MySQL优化了IO、SQL和Worker线程之间的锁等待逻辑，并减少了锁等待次数，从而基本消除了高并发小事务的复制延迟问题。
功能简介
主从复制延迟
复制延迟：大多数业务在高峰期会以较高的并发度更新数据库，当主库业务的并发度高于从库应用的并发度时，就可能导致从库的事务吞吐不如主库，产生复制延迟。在主库业务的并发度很高时，即使调高了Worker线程数或开启了Writeset功能，也可能出现从库复制并发度不够的情况，这是因为从库的IO或者SQL线程已经达到了吞吐的瓶颈。
IO/SQL线程吞吐瓶颈：在MySQL的多线程复制中，有IO、SQL和Worker三类线程：IO线程负责从主库收取binlog event；SQL线程负责将收到的binlog event分发给Worker线程；Worker线程有多个，负责并行应用事务。
其中，IO与SQL线程、SQL与Worker线程之间都存在由锁保护的等待和通知操作，每个binlog event都需要加锁通知一次。每个事务都由多个binlog event组成，例如sysbench write_only这个常用的测试脚本中，一个事务会更新2行，插入1行，删除1行；体现在binlog中，一个事务就有11个event。因此，在高并发时这些锁经常成为性能瓶颈，影响IO线程和SQL线程的吞吐。
当IO或SQL线程达到吞吐瓶颈时，Worker线程就无法及时分配到事务去应用，当从库Worker线程应用的并发度小于主库业务的并发度时，就会产生复制延迟。
高并发小事务延迟优化
为了优化高并发小事务的复制延迟问题，AliSQL引入了小事务打包优化，核心思路是：将小事务的多个binlog event合并在一起进行IO和SQL线程的加锁通知，可以显著降低加锁次数，增大IO线程和SQL线程的吞吐。
适用范围
使用高并发小事务延迟优化功能时，需满足以下条件：
使用方法
您可以同时在主库或只读实例设置以下全局参数来开启该功能：
访问RDS实例列表，在上方选择地域，然后单击目标实例ID。
在左侧导航栏中单击参数设置。
在可修改参数页签内搜索
loose_replica_package_transaction_limit_size参数，并配置参数值。参数说明：当参数设置为0时，本功能关闭；当参数大于0时，binlog大小超过此参数的事务，将会使用到本优化。
取值范围：0~1 MB。
推荐值：1 MB。
单击确定，然后单击提交参数，并在弹出的窗口中选择生效的时间段。该参数修改立即生效，无需重启实例。
优化效果
在主库运行sysbench write_only脚本并设置128并发（TPS 8万）模拟60秒的高峰期业务写压力，可以看到：
优化前：从库的复制延迟不断上升，吞吐很低。
优化后：从库无复制延迟，吞吐较优化前提升了近两倍。
