PolarDB MySQL版叢集內建讀寫分離功能。應用程式只需串連一個可读可写（自动读写分离）模式的叢集地址，寫請求會自動轉寄到主節點，讀請求會自動根據各節點的負載（當前未完成的請求數）轉寄到主節點或唯讀節點。
優勢
讀一致性
當用戶端通過讀寫分離地址與後端建立串連後，讀寫分離中介軟體會自動與主節點和各個唯讀節點建立串連。在同一個串連內（同一個session內），讀寫分離中介軟體會根據各個資料庫節點的資料同步程度，來選擇合適的節點，在保證資料正確的基礎上（寫操作之後的讀有正確的結果），實現讀寫請求的負載平衡。
原生支援讀寫分離，提升效能
如果您在雲上通過自己搭建代理層實現讀寫分離，在資料到達資料庫之前需要經歷多個組件的語句解析和轉寄，響應延遲較大。而PolarDB讀寫分離直接內建在已有的高安全鏈路中，沒有任何額外的組件產生消耗，能夠有效降低延遲，提升處理速度。
維護方便
在傳統模式下，您需要在應用程式中配置主節點和每個唯讀節點的串連地址，並且對商務邏輯進行拆分，才能將寫請求發往主節點而將讀請求發往所有節點。
PolarDB提供叢集地址，應用程式串連該地址後即可對主節點和唯讀節點進行讀寫操作，讀寫請求會被自動轉寄，轉寄邏輯完全對使用者透明，可降低維護成本。
同時，您只需添加唯讀節點的個數，即可不斷擴充系統的處理能力，應用程式無需做任何修改。
節點健全狀態檢查，提升資料庫系統的可用性
讀寫分離模組自動對叢集內的所有節點進行健全狀態檢查，當發現某個節點宕機或者延遲超過閾值後，PolarDB將不再分配讀請求給該節點，讀寫請求在剩餘的健康節點間進行分配，以此確保單個唯讀節點發生故障時，不會影響應用的正常訪問。當節點被修複後，PolarDB會自動將該節點納回請求分配體系內。
免費使用，降低資源及維護成本
免費提供讀寫分離功能，無需支付任何額外費用。
請求轉寄邏輯
可讀可寫入模式轉寄邏輯如下：
只發往主節點：
所有DML操作（INSERT、UPDATE、DELETE、SELECT FOR UPDATE）。
所有DDL操作（建表或庫、刪表或庫、變更表結構、許可權等）。
在未開啟事務拆分功能時，所有事務中的請求。
說明開啟事務拆分功能後的路由詳情請參見事務拆分。
使用者自訂函數。
預存程序。
LOCK/UNLOCK TABLES語句。
使用到暫存資料表的請求。
SELECT last_insert_id()。所有對使用者變數的查詢和更改。
binlog dump。
發往唯讀節點或主節點：
說明僅當主库是否接受读選擇為是時會發往主節點。
非事務中的讀請求。
唯讀事務（START TRANSACTION READ ONLY）。
總是發往所有節點：
所有系統變數的更改。
USE命令。
PREPARE和DEALLOCATE PREPARE命令。
COM_CHANGE_USER、COM_RESET_CONNECTION、COM_QUIT、COM_SET_OPTION等命令。
SHOW PROCESSLIST。說明執行
SHOW PROCESSLIST命令後，PolarDB將返回所有節點的PROCESSLIST資訊。KILL（SQL語句中的KILL，非命令KILL）。
唯讀模式轉寄邏輯如下：
不允許執行DDL、DML操作。
所有讀請求按照負載平衡的方式轉寄到各個唯讀節點。
所有讀請求不會轉寄到主節點。即使主節點已被添加到服務節點中，也不會生效。
binlog dump鎖定到某個RO節點。