在數(shù)據(jù)庫(kù)安裝完畢，對(duì)于binlog日志參數(shù)設(shè)置，有一些參數(shù)的調(diào)整，來(lái)滿足業(yè)務(wù)需求或使性能最大化。Mysql日志主要對(duì)io性能產(chǎn)生影響，本次主要關(guān)注binlog 日志。
?
查一下二進(jìn)制日志相關(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存儲(chǔ)引擎特有的與binlog相關(guān)的參數(shù)，默認(rèn)是關(guān)閉的
?
binlog_cache_size:默認(rèn)大小是37268即32K.在事務(wù)過(guò)程中容納二進(jìn)制日志SQL語(yǔ)句的緩存大小。二進(jìn)制日志緩存是服務(wù)器支持事務(wù)存儲(chǔ)引擎并且服務(wù)器啟用了二進(jìn)制日志(―log-bin選項(xiàng))的前提下為每個(gè)客戶端分配的內(nèi)存，

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

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

? ----使用二進(jìn)制日志緩存的事務(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.
?
? ----使用二進(jìn)制日志緩存并且值達(dá)到了binlog_cache_size設(shè)置的值，用臨時(shí)文件存儲(chǔ)來(lái)自事務(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是否夠用？查看下運(yùn)行情況：

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

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

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

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

當(dāng)我們執(zhí)行多語(yǔ)句事務(wù)的時(shí)候，max_binlog_cache_size如果不夠大的話，系統(tǒng)可能會(huì)報(bào)出“Multi-statementtransactionrequiredmorethan'max_binlog_cache_size'bytesofstorage”的錯(cuò)誤。

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

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

這一點(diǎn)和Oracle的Redo日志有點(diǎn)不一樣，因?yàn)镺racle的Redo日志所記錄的是數(shù)據(jù)文件的物理位置的變化，而且里面同時(shí)記錄了Redo和Undo相關(guān)的信息，所以同一個(gè)事務(wù)是否在一個(gè)日志中對(duì)Oracle來(lái)說(shuō)并不關(guān)鍵。

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

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

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

sync_binlog=n，當(dāng)每進(jìn)行n次事務(wù)提交之后，MySQL將進(jìn)行一次fsync之類的磁盤(pán)同步指令來(lái)將binlog_cache中的數(shù)據(jù)強(qiáng)制寫(xiě)入磁盤(pán)。

在MySQL中系統(tǒng)默認(rèn)的設(shè)置是sync_binlog=0，也就是不做任何強(qiáng)制性的磁盤(pán)刷新指令，這時(shí)候的性能是最好的，但是風(fēng)險(xiǎn)也是最大的。因?yàn)橐坏┫到y(tǒng)Crash，在binlog_cache中的所有binlog信息都會(huì)被丟失。

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

對(duì)于高并發(fā)事務(wù)的系統(tǒng)來(lái)說(shuō)，“sync_binlog”設(shè)置為0和設(shè)置為1的系統(tǒng)寫(xiě)入性能差距可能高達(dá)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)打開(kāi)SlowQueryLog功能，而long_query_time參數(shù)則告訴我們當(dāng)前系統(tǒng)設(shè)置的SlowQuery記錄執(zhí)行時(shí)間超過(guò)多長(zhǎng)的Query。

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

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

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

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

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

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

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

總結(jié)

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

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