Beta 機器測試，寫入性能較差，有 4ms+，於是與DB共同排查，確實是分庫DB寫入太慢，DB 調整了兩個參數後，RT 下降到均值 2ms。是什麼參數如此給力？ 這樣調整後，32C-96G-1000G 單庫峯值 TPS = 2.6W，QPS = 1.1W
具體操作是，innodb_flush_log_at_trx_commit 從1改爲2，sync_binlog 從1改爲 10000 ，前者是 InnoDB 引擎特有的。
1、 innodb_flush_log_at_trx_commit
innodb_flush_log_at_trx_commit 參數可以理解爲 InnoDB 在事務提交後的日誌寫入頻率。
當 innodb_flush_log_at_trx_commit 取值爲 0 的時候，log buffer 會 每秒寫入到日誌文件並刷寫（flush）到磁盤。但每次事務提交不會有任何影響，也就是 log buffer 的刷寫操作和事務提交操作沒有關係。在這種情況下，MySQL性能最好，但如果 mysqld 進程崩潰，通常會導致最後 1s 的日誌丟失。
當取值爲 1 時，每次事務提交時，log buffer 會被寫入到日誌文件並刷寫到磁盤。這也是默認值。這是最安全的配置，但由於每次事務都需要進行磁盤I/O，所以也最慢。
當取值爲 2 時，每次事務提交會寫入日誌文件，但並不會立即刷寫到磁盤，日誌文件會每秒刷寫一次到磁盤。這時如果 mysqld 進程崩潰，由於日誌已經寫入到系統緩存，所以並不會丟失數據；在操作系統崩潰的情況下，通常會導致最後 1s 的日誌丟失。
上面說到的「最後 1s」並不是絕對的，有的時候會丟失更多數據。有時候由於調度的問題，每秒刷寫（once-per-second flushing）並不能保證 100% 執行。對於一些數據一致性和完整性要求不高的應用，配置爲 2 就足夠了；如果爲了最高性能，可以設置爲 0。有些應用，如支付服務，對一致性和完整性要求很高，所以即使最慢，也最好設置爲 1.
2. sync_binlog
sync_binlog 是 MySQL 的二進制日誌（binary log）同步到磁盤的頻率。MySQL server 在 binary log 每寫入 sync_binlog=N 次後，刷寫到磁盤。
如果 autocommit 開啓，每個語句都寫一次 binary log，否則每次事務寫一次。默認值是 0，不主動同步，而依賴操作系統本身不定期把文件內容 flush 到磁盤。設爲 1 最安全，在每個語句或事務後同步一次 binary log，即使在崩潰時也最多丟失一個語句或事務的日誌，但因此也最慢。
大多數情況下，對數據的一致性並沒有很嚴格的要求，所以並不會把 sync_binlog 配置成 1. 爲了追求高併發，提升性能，可以設置爲 N 或直接用 0. 而和 innodb_flush_log_at_trx_commit 一樣，對於支付服務這樣的應用，還是比較推薦 sync_binlog = 1.