在數(shù)據(jù)庫安裝完畢，對于binlog日志參數(shù)設(shè)置，有一些參數(shù)的調(diào)整，來滿足業(yè)務(wù)需求或使性能最大化。Mysql日志主要對io性能產(chǎn)生影響，本次主要關(guān)注binlog 日志。
?
查一下二進制日志相關(guān)的參數(shù)??
?
mysql> show variables like '%binlog%';
+-----------------------------------------+----------------------+
| Variable_name?????????????????????????? | Value??????????????? |
+-----------------------------------------+----------------------+
| binlog_cache_size?????????????????????? | 32768??????????????? |
| binlog_checksum???????????????????????? | CRC32??????????????? |
| binlog_direct_non_transactional_updates | OFF????????????????? |
| binlog_format?????????????????????????? | STATEMENT??????????? |
| binlog_max_flush_queue_time???????????? | 0??????????????????? |
| binlog_order_commits??????????????????? | ON?????????????????? |
| binlog_row_image??????????????????????? | FULL???????????????? |
| binlog_rows_query_log_events??????????? | OFF????????????????? |
| binlog_stmt_cache_size????????????????? | 32768??????????????? |
| innodb_api_enable_binlog??????????????? | OFF????????????????? |
| innodb_locks_unsafe_for_binlog????????? | OFF????????????????? |
| max_binlog_cache_size?????????????????? | 18446744073709547520 |
| max_binlog_size???????????????????????? | 1073741824?????????? |
| max_binlog_stmt_cache_size????????????? | 18446744073709547520 |
| sync_binlog???????????????????????????? | 0??????????????????? |
+-----------------------------------------+----------------------+

?
其中innodb_locks_unsafe_for_binlog 參數(shù)是innodb存儲引擎特有的與binlog相關(guān)的參數(shù)，默認是關(guān)閉的
?
binlog_cache_size:默認大小是37268即32K.在事務(wù)過程中容納二進制日志SQL語句的緩存大小。二進制日志緩存是服務(wù)器支持事務(wù)存儲引擎并且服務(wù)器啟用了二進制日志(―log-bin選項)的前提下為每個客戶端分配的內(nèi)存，

注意，是每個Client都可以分配設(shè)置大小的binlogcache空間。如果讀者朋友的系統(tǒng)中經(jīng)常會出現(xiàn)多語句事務(wù)的華，可以嘗試增加該值的大小，以獲得更有的性能;

我們可以通過以下兩個狀態(tài)變量判斷binlog_cache_size的使用情況：
?
1)binlog_cache_use: The number of transactions that used the temporary binary log cache.

? ----使用二進制日志緩存的事務(wù)的數(shù)量

2)binlog_cache_disk_use: The number of transactions that used the binary log cache but that exceeded the value of binlog_cache_size and used a temporary file to store changes from the transaction.
?
? ----使用二進制日志緩存并且值達到了binlog_cache_size設(shè)置的值，用臨時文件存儲來自事務(wù)的變化這樣的事務(wù)數(shù)量

==

我們看看配置文件：

[@hostname ~]# grep 'binlog' /data/mydata/my3306/my3306.cnf
binlog_cache_size = 64M??
binlog_format = mixed
max_binlog_cache_size = 128M
max_binlog_size = 200M
sync_binlog = 0

[@hostname ~]#

我們看看配置64M是否夠用？查看下運行情況：

mysql> show status like 'binlog_%';
+-----------------------+-----------+
| Variable_name???????? | Value???? |
+-----------------------+-----------+
| Binlog_cache_disk_use | 0???????? |
| Binlog_cache_use????? | 120402264 |
+-----------------------+-----------+
2 rows in set (0.00 sec)

運行情況Binlog_cache_use 表示binlog_cache內(nèi)存方式被用上了多少次，Binlog_cache_disk_use表示binlog_cache臨時文件方式被用上了多少次。

Binlog_cache_disk_use現(xiàn)在等于0，表示內(nèi)存cache是夠用的，從來不需要使用到臨時文件。如果沒有l(wèi)ong_transaction的話，覺得64M是偏大的。

---
?
Max_binlog_cache_size: 默認值是18446744073709547520，這個值很大，夠我們使用的了。此參數(shù)和binlog_cache_size相對應(yīng)，是所代表的是binlog能夠使用的最大cache內(nèi)存大小。

當我們執(zhí)行多語句事務(wù)的時候，max_binlog_cache_size如果不夠大的話，系統(tǒng)可能會報出“Multi-statementtransactionrequiredmorethan'max_binlog_cache_size'bytesofstorage”的錯誤。

Max_binlog_size: 1073741824=1G? binlog的最大值，一般設(shè)置為512M或1G,一般不能超過1G;

該大小并不能非常嚴格控制Binlog大小，尤其是當?shù)竭_Binlog比較靠近尾部而又遇到一個較大事務(wù)的時候，系統(tǒng)為了保證事務(wù)的完整性，不可能做切換日志的動作，只能將該事務(wù)的所有SQL都記錄進入當前日志，直到該事務(wù)結(jié)束。

這一點和Oracle的Redo日志有點不一樣，因為Oracle的Redo日志所記錄的是數(shù)據(jù)文件的物理位置的變化，而且里面同時記錄了Redo和Undo相關(guān)的信息，所以同一個事務(wù)是否在一個日志中對Oracle來說并不關(guān)鍵。

而MySQL在Binlog中所記錄的是數(shù)據(jù)庫邏輯變化信息，MySQL稱之為Event，實際上就是帶來數(shù)據(jù)庫變化的DML之類的Query語句。

sync_binlog：這個參數(shù)是對于MySQL系統(tǒng)來說是至關(guān)重要的，他不僅影響到Binlog對MySQL所帶來的性能損耗，而且還影響到MySQL中數(shù)據(jù)的完整性。對于“sync_binlog”參數(shù)的各種設(shè)置的說明如下：

sync_binlog=0，當事務(wù)提交之后，MySQL不做fsync之類的磁盤同步指令刷新binlog_cache中的信息到磁盤，而讓Filesystem自行決定什么時候來做同步，或者cache滿了之后才同步到磁盤。

sync_binlog=n，當每進行n次事務(wù)提交之后，MySQL將進行一次fsync之類的磁盤同步指令來將binlog_cache中的數(shù)據(jù)強制寫入磁盤。

在MySQL中系統(tǒng)默認的設(shè)置是sync_binlog=0，也就是不做任何強制性的磁盤刷新指令，這時候的性能是最好的，但是風(fēng)險也是最大的。因為一旦系統(tǒng)Crash，在binlog_cache中的所有binlog信息都會被丟失。

而當設(shè)置為“1”的時候，是最安全但是性能損耗最大的設(shè)置。因為當設(shè)置為1的時候，即使系統(tǒng)Crash，也最多丟失binlog_cache中未完成的一個事務(wù)，對實際數(shù)據(jù)沒有任何實質(zhì)性影響。從以往經(jīng)驗和相關(guān)測試來看，

對于高并發(fā)事務(wù)的系統(tǒng)來說，“sync_binlog”設(shè)置為0和設(shè)置為1的系統(tǒng)寫入性能差距可能高達5倍甚至更多。

==========

Slow Query Log 相關(guān)參數(shù)及使用建議
--
mysql> show variables like 'log_slow%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| log_slow_queries | ON |
+------------------+-------+
1 row in set (0.00 sec)

mysql> show variables like 'long_query%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| long_query_time | 1 |
+-----------------+-------+
1 row in set (0.01 sec)

log_slow_queries---參數(shù)顯示了系統(tǒng)是否已經(jīng)打開SlowQueryLog功能，而long_query_time參數(shù)則告訴我們當前系統(tǒng)設(shè)置的SlowQuery記錄執(zhí)行時間超過多長的Query。

在MySQLAB發(fā)行的MySQL版本中SlowQueryLog可以設(shè)置的最短慢查詢時間為1秒，這在有些時候可能沒辦法完全滿足我們的要求，如果希望能夠進一步縮短慢查詢的時間限制，可以使用Percona提供的microslow-patch（件成為mslPatch）來突破該限制。

mslpatch不僅僅能將慢查詢時間減小到毫秒級別，同時還能通過一些特定的規(guī)則來過濾記錄的SQL，如僅記錄涉及到某個表的SlowQuery等等附加功能。

考慮到篇幅問題，這里就不介紹mslpatch給我們帶來的更為詳細的功能和使用，大家請參考官方介紹（http://www.mysqlperformanceblog.com/2008/04/20/updated-msl-microslow-patch-installation-walk-through/）

打開SlowQueryLog功能對系統(tǒng)性能的整體影響沒有Binlog那么大，畢竟SlowQueryLog的數(shù)據(jù)量比較小，帶來的IO損耗也就較小，但是，系統(tǒng)需要計算每一條Query的執(zhí)行時間，所以消耗總是會有一些的，主要是CPU方面的消耗。

如果大家的系統(tǒng)在CPU資源足夠豐富的時候，可以不必在乎這一點點損耗，畢竟他可能會給我們帶來更大性能優(yōu)化的收獲。但如果我們的CPU資源也比較緊張的時候，也完全可以在大部分時候關(guān)閉該功能，而只需要間斷性的打開SlowQueryLog功能來定位可能存在的慢查詢。

MySQL的其他日志由于使用很少（QueryLog）或者性能影響很少，我們就不在此過多分析了，至于各個存儲引擎相關(guān)的日志，我們留在后面“常用存儲引擎優(yōu)化”部分再做相應(yīng)的分析。

轉(zhuǎn)自《mysql性能調(diào)優(yōu)與架構(gòu)設(shè)計》

總結(jié)

以上是生活随笔為你收集整理的mysql binlog日志优化及思路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。