mysql中日志類型有慢查詢日志，二進制日志，錯誤日志，默認情況下，系統只打開錯誤日志，因為開啟日志會產生較大的IO性能消耗。
一般情況下，生成系統中很少打開二進制日志（bin log），bin log日志的優化策略：
mysql> show variables like '%binlog%';
+-----------------------------------------+----------------------+
| Variable_name | Value |
+-----------------------------------------+----------------------+
| binlog_cache_size | 32768 |
| binlog_checksum | CRC32 |
| binlog_direct_non_transactional_updates | OFF |
| binlog_format | ROW |
| 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 |
| binlogging_impossible_mode | IGNORE_ERROR |
| 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 |
+-----------------------------------------+----------------------+
binlog_cache_size：在事務過程中，用來保存二進制SQL語句的緩存大小。二進制日志緩存使用的前提條件是服務器端使用了支持事務的引擎以及開啟了bin log功能。
該參數為每個客戶端都分配binlog_cache_size大小的緩存，如果用戶頻繁使用多語句事務的話，可以增大binlog_cache_size大小，已獲得更好的性能，如何判斷binlog_cache_size
設置的是否合理呢？通過如下兩個狀態可以判斷：
mysql> show status like 'binlog%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| Binlog_cache_disk_use | 1 |
| Binlog_cache_use | 33 |
+----------------------------+-------+
max_binlog_size ：binlog大小的最大值，一般為512M或1G，但不能超過1G，該大小不能嚴格控制binlog日志大小，如果在binlog大小臨界點的時候執行了一個大事務，為了保證事務完整性，不能做日志切換，只能將該事務的所有sql記錄當前日志中。其實mysql的binlog日志記錄的是帶來數據改變的DML，DDL操作
sync_binlog：該參數用來控制以何種方式將binlog cache中的記錄同步（fsync）到磁盤。以下是它的參數值的說明；
sync_binlog=0: 表示當事務提交后，不立即將binlog cache中的記錄同步到磁盤，具體何時同步，讓文件系統自行決定，或者cache滿了之后才同步。這種方式性能最好，都是風險也最大，一旦系統宕機，binlog cache中所有的記錄都會丟失，如果將sync_binlog值設為1的話，最安全，因為即使系統宕機，也只丟失一個事務的操作記錄，都是性能最差，事務每提交一次就會將binlog_cache中的記錄同步到磁盤。
sync_binlog=n: 表示事務多少次提交后才將binlog cache中的記錄同步到磁盤
mysql的主從同步就是slave端通過IO線程將master端產生的日志同步到slave端的中繼日志，然后通過SQL線程將中繼日志在slave端重演。所以master端的日志量大小，直接影響了salve端同步的性能，通常情況下，master端產生binlog日志量是無法避免的，但是可以通過設置參數有選擇性地同步哪些數據庫或表產生的binlog日志來減少binlog日志同步量。
binlog_do_db：設置哪些數據庫需要記錄binlog（master端）
binlog_ignore_db:設置哪些數據庫不需要記錄binlog（master端）
replicate_do_db：設置哪些數據庫需要同步binlog，多個數據庫用逗號”，“隔開
replicate_ignore_db：設置哪些數據庫不需要同步binlog，多個數據庫用逗號”，“隔開
replicate_do_table:設置哪些表需要同步binlog
replicate_ignore_table:設置哪些表不需要同步binlog
replicate_wild_do_table:設置哪些表需要同步binlog，與replicate_do_table的區別是可以使用通配符的方式來指定表
replicate_wild_ignore_table：設置哪些表不需要同步binlog，與replicate_ignore_table的區別是可以使用通配符的方式來指定表
如果在master端設置了上面兩個參數。會減少master端binlog日志的記錄量，降低master端日志IO量，減少同步到slave端時的網絡通信量，進而降低lave端IO線程同步日志量和SQL線程應用relay log量。但是需要注意的是，mysql判斷是否復制某個event不是根據產生該event的query中指定的db名來記錄的，而是根據執行該query時所在的db（即using dbname）是否是binlog_do_db指定的db，若是，則記錄，否則不記錄。考慮如下場景：
有三個數據庫：A，B，C，其中binlog_do_db=B，C
應用登錄時默認db是A，現執行如下query：update B.t1 set c1 = xxx；這種情況下，mysql是不記錄binlog的，由於對B庫下的t1表的update操作不記錄binlog，所以無法同步到slave端，進而會導致master與slave數據不一致。
如果所在db等於binlog_do_db，此時修改了不需要同步的db下的表也會記錄binlog日志，即該db下所有改變db數據的query都會記錄binlog
即應用登錄db是B，執行query：update A.t1 set c1=xxx；此時也會記錄binlog日志。由於binlog_do_db中沒有A庫，所以slave端不會有A庫，從而導致slave端無法找到A庫而報錯。
如果在slave端設置后面六個參數，無論master該復制或不該復制的event都會被同步到slave端，這樣帶來的負面影響是IO，網絡的壓力，和slave端IO線程寫入relay log的壓力，但是可以減少slave端SQL線程應用relay log的日志量，由於設置了replicate_do_db，replicate_ignore_db會過濾相應的日志，所以可以規避默認db是否等於binlog_do_db問題。