RDS MySQL 最佳化了並行複製的等待邏輯，有效消除了批量資料處理期間產生的複寫延遲。該功能特別適用於在業務低峰期進行批量資料刪除、整理、匯入等操作的情境。
適用範圍
資料庫版本需滿足以下要求：
RDS MySQL 8.4
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線程中等待並阻塞其他事務的分發。這樣，沒有衝突的中等事務就能夠並發執行了。