1.mysql有許多系統變量，可以設置，系統變量設置不同，不同的系統將導致執行狀態。故mysql提供兩組命令，分別查看系統設置和執行狀態。
1、系統設置：
SHOW [GLOBAL | SESSION] VARIABLES [like_or_where]SHOW VARIABLES shows the values of MySQL system variables.
2、執行狀態：
SHOW [GLOBAL | SESSION] STATUS [like_or_where]
SHOW STATUS provides server status information.
備注：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了。
2.Binlog 相關參數及優化策略。
binlog_cache_size
Binlog_cache_disk_use
Binlog_cache_use
max_binlog_cache_size
max_binlog_size
sync_binlog
“binlog_cache_size"：在事務過程中容納二進制日志SQL語句的緩存大小。
二進制日志緩存是server支持事務存儲引擎而且server啟用了二進制日志(—log-bin選項)的前提下為每一個client分配的內存，注意，是每一個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
+-----------------------+-----------+
| Binlog_cache_disk_use | 0
| Binlog_cache_use
+-----------------------+-----------+
“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時報或其他許多。
版權聲明：本文博主原創文章，博客，未經同意不得轉載。