MySQL redo log是一個順序寫的單緩沖區，log_sys->mutex鎖資源竟爭激烈，在事務落盤的過程中對LSN相關的讀、寫都被阻塞，為了解決 log_sys->mutex的鎖竟爭問題，引入雙緩沖區機制&w_mutex鎖，在flush redo log 的過程中釋放log_sys->mutex，繼續持有log_sys->w_mutex，從而阻塞寫，不阻塞LSN相關的讀操作，flush完成后釋放w_mutex;從而提升并發性，提升性能。

　　TXSQL性能數據對比

　　TXSQL功能開發

　　在TXSQL并行復制方面，MySQL并行復制存在的問題：在實際的應用環境中，實例中往往只有一個 Database，導致 relay log 中的事務大部分會分到同一個 worker 線程中，造成備庫的性能低下，當主庫的性能超過備庫的單線程執行的性能時，就會出現延遲，對只讀實例產生影響。

　　TXSQL并行復制存在的優化

　　為了解決上述問題，TXSQL 添加了另外一種分發方式，即基于表粒度的分發，為了實現基于表粒度的分發，TXSQL 對于不同的實現，進行了不同的處理:

　　當binlog_row_format= ROW 時, 調用 get_slave_worker 直接進行分發;

　　當 binlog_row_format= statement 時，則需要對語句先進行調用 mysql_parse 對語句進行解析，然后再做分發。

　　TXSQL強同步支持

　　原生 semi-sync 存在著以下問題：

　　semi-sync 在時間超過 rpl_semi_sync_master_timeout 會退化為異步;

　　采用 select 進行監聽，當句柄值大于 1024 時則會出現異常，詳情可參考 bug#79865;

　　在 after commit 后等待 ACK 容易出現幻讀的問題;

　　TXSQL 強同步支持：

　　優化半同步，增加ack線程，收發并行化;

　　修正select時fd超過1024導致異常的bug，改為poll;

　　在半同步基礎上實現強同步，一直hold住直到收到ack;

　　修改同步方式時，喚醒正在等待的用戶線程，繼續等待或者退出;

　　增加一些狀態，用于展示當前等待的情況(正在等待的binlog位點，已等待時間);

　　對于主多 binlog 備少 binlog 的情況進行特殊的處理，以保證雙寫的情況不會發生;

　　TXSQL云上實踐

　　XX游戲數據庫優化案例

　　問題現象：性能不能滿足業務要求，游戲業務邏輯 TPS 不達標;在壓力達到一定程度時，CPU 不能充分利用，idle 較高;性能抖動較為明顯; thread running 過高，系統負載較高;系統 IO 壓力較小，IO 沒有問題;

　　問題排查：

　　pt-pmp & pstack & mysql 命令進行問題排查，發現以下問題：