大多數業務在高峰期會以較高的並發度更新資料庫，當主庫業務的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秒的高峰期業務寫壓力，可以看到：
最佳化前：從庫的複寫延遲不斷上升，吞吐很低。
最佳化後：從庫無複寫延遲，吞吐較最佳化前提升了近兩倍。
