1.mysql數據庫服務相關的幾類日誌文件
1.1 錯誤日誌error log:記錄mysql服務進程mysqld在啓動、關閉或運行過程中遇到的幾類日誌文件
1.2 查詢日誌query log：
1.2.1 普通查詢日誌 general query log:記錄客戶端連接信息和執行的sql語句信息
1.2.2 慢查詢日誌 slow query log:記錄執行時間超出指定值long_query_time 的sql語句。
1.3 二進制日誌binary log:記錄數據唄修改的相關信息
2.二進制文件配置在my.cnf中，log-bin參數值。
show variables like '%log_bin%';
log_bin ON 是否打開binlog記錄的開關
sql_log_bin ON 臨時記錄不記錄
錯誤日誌文件配置在my.cnf中,log-error參數值。
普通查詢日誌，執行show variables like 'general%';即可查看開關狀態加文件路徑。可執行set global general_log=ON,來打開。
慢查詢日誌文件配置在my.cnf中，超過1秒就寫。
long_query_time = 1
#log-slow-queries = /data/3306/slow.log
log_queries_not_using_indexes //沒使用索引的語句記錄到 log。該參數可通過show variables like '%index%'得到。
3.binlog日誌的三種模式
3.1 statement level 模式
每一條會修改數據的sql都會記錄到master的binlog中，slave在複製的時候sql進程會解析成和原來master端執行過的相同的sql來再次執行。
優點：解決了row level下的缺點，不需要記錄每一行數據的變化，減少binlog日誌量，節約io，提高性能，因爲只需要記錄在master上所執行語句的細節，
以及執行語句時候的上下文的信息。
缺點： 由於MySQL發展快，很多新功能不斷加入，使得mysql的複製遇到了挑戰，目前已經發現有不少情況會造成複製出現問題，主要是修改數據的時候使用了
特定的函數或者功能的時候會出現，比如sleep()函數在有些版本中不能正確複製，在存儲過程中使用了last_insert_id()函數，會使得slave和master得到不一致
的id，
3.2 row level行級模式
日誌中會記錄成每一行數據被修改的形式，然後在slave端再對相同的數據進行修改, 查看日誌文件:mysqlbinlog --base64-output=decode-rows -v mysql-bin.000006
優點：清楚的記錄下每一行數據修改的細節，容易立即，而且不會出現某些特定情況下的存儲過程或者函數而導致無法被正確複製的問題
缺點：會產生大量的日誌內容，尤其是update很多數據的時候，或者是當執行alter table之類的語句的時候，因爲mysql對於alter table表結構變更語句的處理是整個表的
每一條記錄都需要變動，實際就是重建表，那麼該表的每一條記錄都會被記錄到日誌中，
3.3 mixed 模式
前兩種的結合，mysql會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，新版本的s level還是和以前一樣，只記錄執行語句，
而新版的r level模式被做了優化，並不是所有的修改都會以row level來記錄，像遇到表結構變更的時候會以 s level來記錄，
3.4 調整模式
3.4.1 查看模式
show variables like 'binlog_format';
3.4.2 在線修改立即生效
運行時修改：set session binlog_format='STATEMENT';// ROW/MIXED
全局生效：set global binlog_format='STATEMENT';//ROW/MIXED
永久生效，修改配置文件 binlog_format=mixed