共計 3397 個字符，預計需要花費 9 分鐘才能閱讀完成。
這篇文章給大家介紹 MySQL 中有哪些日志維護策略，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
日志類型：
MySQL 有幾個不同的日志文件，可以幫助你找出 mysqld 內部發生的事情：
日志文件記入文件中的信息類型 錯誤日志記錄啟動、運行或停止時出現的問題 查詢日志記錄建立的客戶端連接和執行的語句二進制日志記錄所有更改數據的語句。主要用于復制和即時點恢復慢日志記錄所有執行時間超過 long_query_time 秒的所有查詢或不使用索引的查詢事務日志記錄 InnoDB 等支持事務的存儲引擎執行事務時產生的日志
1. 啟動慢查詢日志：
MySQL 如果啟用了 slow_query_log=ON 選項，就會記錄執行時間超過 long_query_time(默認 10s)的查詢(初使表鎖定的時間不算作 執行 時間)。日志記錄文件為 slow_query_log_file[=file_name]，如果沒有給出 file_name 值， 默認為主機名，后綴為 -slow.log。如果給出了文件名，但不是絕對路徑名，文件則寫入數據目錄。
【這個可以在調試 mysql 性能的時候啟用, 可以找出是哪個 sql 指令最浪費時間。生產環境中建議關閉】
2. 生產環境中關閉通用查詢日志：
由 于打開通用查詢日志是記錄用戶的所有操作，在生產環境中這個日志的量是非常大的，所以一般情況下都是不打開的，myslq 默認的該日志功能也是關閉的，在 特殊情況下才進行打開【一般只有在開發測試環境中，為了定位某些功能具體使用了哪些 SQL 語句的時候，才會在短時間段內打開該日志來做相應的分析。】
mysql set global general_log = 1; #1：啟動通用查詢日志，0：關閉通用查詢日志
mysql show global variables like %general_log%
+------------------+----------------------------+ | Variable_name | Value | +------------------+----------------------------+ | general_log | ON | #是否啟用了通用查詢日志 | general_log_file | /var/run/mysqld/mysqld.log | # 日志路徑 +------------------+----------------------------+2 rows in set (0.00 sec)
3. 定期備份二進制日志和 sql 數據：【本地一份，遠程日志主機一份，存儲主機一份】
在 my.cnf 中 log-bin = [filename]是啟用二進制日志，默認以 [filename].000001 往上記錄的，從啟用 log-bin 之后【此時 *** 用 mysqldump 保存當前的 mysql 某個庫的數據，因為二進制日志只是記錄了從現在起到最近一次 mysql 當機重啟中的所有 sql 語句】，mysql 就會開始記錄每一個 sql 語句，一旦 mysql 因各種原因需要重啟，則會產生新的二進制日志，000001 的后綴名會不斷往上自加。若是在 mysql 當機期間 mysql 的數 據遭到了破壞(如磁盤損壞)，之前的數據全部都被破壞了，這時候這個備份策略就可以幫你挽回損失。你可以從二進制日志中恢復從開始到最近一次 mysql 重 啟這段時間的數據。【二進制日志中記錄的是每一個 sql 語句，可以用 mysqlbinlog [filename] 查看日志內容】
4.sync_binlog 全局變量的取值一定要合適：
默 認情況下，并不是每次寫入時都將二進制日志與硬盤同步。因此如果操作系統或機器 (不僅僅是 MySQL 服務器) 崩潰，有可能二進制日志中 *** 的語句丟失了。要想防止這種情況，你可以使用 sync_binlog 全局變量(1 是最安全的值，但也是最慢的)，使二進制日志在每 N 次二進制日志寫入后與硬盤同步。對非 事務表的更新執行完畢后立即保存到二進制日志中。
下面解釋下 sync_binlog:
“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 倍甚至更多。
5. 如果數據庫有很多的事務型操作，則建議把二進制日志的回滾上限設置大一些：
對于事務表，例如 BDB 或 InnoDB 表，所有更改表的更新 (UPDATE、DELETE 或 INSERT) 被緩存起來，直到服務器接收到 COMMIT 語句。在該點，執行完 COMMIT 之前，mysqld 將整個事務寫入二進制日志。當處理事務的線程啟動時，它為 緩沖查詢分配 binlog_cache_size 大小的內存。如果語句大于該值，線程則打開臨時文件來保存事務【所以如果 bunlog_cache_size 足夠大，就避免了過多的磁盤的 I / O 操作, 可以把數據全部緩存在內存中】。線程結束后臨時文件被刪除。【“max_binlog_cache_size”：和 binlog_cache_size 相對應，但是所代表的是 binlog 能夠使用的 *** cache 內存大小。當我們執行多語句事務的時候，max_binlog_cache_size 如果不夠大的話，系統可能會報出“Multi- statementtransactionrequiredmorethan max_binlog_cache_size bytesofstorage”的錯誤。所以 *** 也把 max_binlog_cache_size 也調大些(具體多大看你的服務器了)】
6. 盡量把 max_binlog_size 設置大些
Binlog 日志 *** 值，一般來說設置為 512M 或者 1G，但不能超過 1G。該大小并不能非常嚴格控制 Binlog 大小，尤其是當到達 Binlog 比較靠近尾部而又遇到一個較大事務的時候，系統為了保證事務的完整性，不可能做切換日志的動作，只能將該事務的所有 SQL 都記錄進入當前日志，直到該事務 結束。
7. 下面是 mysql 環境的情況：
mysql show variables like %binlog%
+--------------------------------+------------+ | Variable_name | Value | +--------------------------------+------------+
| binlog_cache_size | 1048576 |
| innodb_locks_unsafe_for_binlog | OFF |
| max_binlog_cache_size| 4294967295 |
| max_binlog_size| 1073741824 |
| sync_binlog| 0|
+--------------------------------+------------+
關于 MySQL 中有哪些日志維護策略就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
