1、系統設置：
SHOW [GLOBAL | SESSION] VARIABLES [like_or_where]備注：SHOW XXX 可能會顯示很多內容，類似Linux下內容太多了，往往需要grep來過濾，那麼mysql也考慮到了這點，使用LIKE字句可以過濾。
在安裝完MySQL之後，肯定是需要對MySQL的各種參數選項進行一些優化調整的。雖然MySQL系統的伸縮性很強，既可以在有很充足的硬件資源環境下高效的運行，也可以在極少資源環境下很好的運行，但不管怎樣，盡可能充足的硬件資源對MySQL的性能提升總是有幫助的。在這一節我們主要分析一下MySQL的日志（主要是Binlog）對系統性能的影響，並根據日志的相關特性得出相應的優化思路。
日志產生的性能影響
由於日志的記錄帶來的直接性能損耗就是數據庫系統中最為昂貴的IO資源。
在之前介紹MySQL物理架構的章節中，我們已經了解到了MySQL的日志包括錯誤日志（ErrorLog），更新日志（UpdateLog），二進制日志（Binlog），查詢日志（QueryLog），慢查詢日志（SlowQueryLog）等。當然，更新日志是老版本的MySQL才有的，目前已經被二進制日志替代。
在默認情況下，系統僅僅打開錯誤日志，關閉了其他所有日志，以達到盡可能減少IO損耗提高系統性能的目的。但是在一般稍微重要一點的實際應用場景中，都至少需要打開二進制日志，因為這是MySQL很多存儲引擎進行增量備份的基礎，也是MySQL實現復制的基本條件。有時候為了進一步的性能優化，定位執行較慢的SQL語句，很多系統也會打開慢查詢日志來記錄執行時間超過特定數值（由我們自行設置）的SQL語句。
一般情況下，在生產系統中很少有系統會打開查詢日志。因為查詢日志打開之後會將MySQL中執行的每一條Query都記錄到日志中，會該系統帶來比較大的IO負擔，而帶來的實際效益卻並不是非常大。一般只有在開發測試環境中，為了定位某些功能具體使用了哪些SQL語句的時候，才會在短時間段內打開該日志來做相應的分析。所以，在MySQL系統中，會對性能產生影響的MySQL日志（不包括各存儲引擎自己的日志）主要就是Binlog了。
binlog_cache_size
Binlog_cache_disk_use
Binlog_cache_use
max_binlog_cache_size
max_binlog_size
sync_binlog
“binlog_cache_size"：在事務過程中容納二進制日志SQL語句的緩存大小。二進制日志緩存是服務器支持事務存儲引擎並且服務器啟用了二進制日志(—log-bin選項)的前提下為每個客戶端分配的內存，注意，是每個Client都可以分配設置大小的binlogcache空間。如果讀者朋友的系統中經常會出現多語句事務的華，可以嘗試增加該值的大小，以獲得更有的性能。當然，我們可以通過MySQL的以下兩個狀態變量來判斷當前的binlog_cache_size的狀況：Binlog_cache_use和Binlog_cache_disk_use。
Binlog_cache_disk_use:表示因為我們binlog_cache_size設計的內存不足導致緩存二進制日志用到了臨時文件的次數
Binlog_cache_use :表示 用binlog_cache_size緩存的次數
當對應的Binlog_cache_disk_use 值比較大的時候 我們可以考慮適當的調高 binlog_cache_size 對應的值
show global status like 'bin%';
上述語句我們可以得到當前 數據庫binlog_cache_size的使用情況
mysql> show status like 'binlog_%';
+-----------------------+-----------+
| Variable_name | Value |
+-----------------------+-----------+
| Binlog_cache_disk_use | 0 |
| Binlog_cache_use | 120402264 |
+-----------------------+-----------+
“max_binlog_cache_size”：和"binlog_cache_size"相對應，但是所代表的是binlog能夠使用的最大cache內存大小。當我們執行多語句事務的時候，max_binlog_cache_size如果不夠大的話，系統可能會報出“Multi-statementtransactionrequiredmorethan'max_binlog_cache_size'bytesofstorage”的錯誤。
“max_binlog_size”：Binlog日志最大值，一般來說設置為512M或者1G，但不能超過1G。該大小並不能非常嚴格控制Binlog大小，尤其是當到達Binlog比較靠近尾部而又遇到一個較大事務的時候，系統為了保證事務的完整性，不可能做切換日志的動作，只能將該事務的所有SQL都記錄進入當前日志，直到該事務結束。這一點和Oracle的Redo日志有點不一樣，因為Oracle的Redo日志所記錄的是數據文件的物理位置的變化，而且裡面同時記錄了Redo和Undo相關的信息，所以同一個事務是否在一個日志中對Oracle來說並不關鍵。而MySQL在Binlog中所記錄的是數據庫邏輯變化信息，MySQL稱之為Event，實際上就是帶來數據庫變化的DML之類的Query語句。
“sync_binlog”：這個參數是對於MySQL系統來說是至關重要的，他不僅影響到Binlog對MySQL所帶來的性能損耗，而且還影響到MySQL中數據的完整性。對於“sync_binlog”參數的各種設置的說明如下：
sync_binlog=0，當事務提交之後，MySQL不做fsync之類的磁盤同步指令刷新binlog_cache中的信息到磁盤，而讓Filesystem自行決定什麼時候來做同步，或者cache滿了之後才同步到磁盤。
sync_binlog=n，當每進行n次事務提交之後，MySQL將進行一次fsync之類的磁盤同步指令來將binlog_cache中的數據強制寫入磁盤。
在MySQL中系統默認的設置是sync_binlog=0，也就是不做任何強制性的磁盤刷新指令，這時候的性能是最好的，但是風險也是最大的。因為一旦系統Crash，在binlog_cache中的所有binlog信息都會被丟失。而當設置為“1”的時候，是最安全但是性能損耗最大的設置。因為當設置為1的時候，即使系統Crash，也最多丟失binlog_cache中未完成的一個事務，對實際數據沒有任何實質性影響。從以往經驗和相關測試來看，對於高並發事務的系統來說，“sync_binlog”設置為0和設置為1的系統寫入性能差距可能高達5倍甚至更多。
