錯誤日志：
啟動、運行、停止 mysqld(MySQL Server) 遇到的問題
通用查詢日志：
建立客戶端連接和從客戶端接收的語句
二進制日志：
更改數據的語句（也用於復制）
中繼日志：
從復制master server接收到的數據更改
慢查詢日志：
執行查詢超過long_query_time 系統變量指定的秒數
DDL日志（元數據日志）：
DDL語句執行的元數據操作
通過刷新日志可以強制服務器關閉並重新打開日志文件（有時還會生成一個新的日志文件）
刷新日志文件方法：
mysql> flush logs;
mysql> mysqladmin flush-logs
mysql> mysqladmin refresh
shell> mysqldump --flush-logs
此外，當二進制日志的大小達到 max_binlog_size 系統變量設置也會刷新該日志
注：官檔中提到 mysqldump 的 --master-data 選項也可會刷新日志，測試發現不能
通用查詢日志和慢查詢日志的一些說明：
log_output 系統變量：控制通用查詢日志和慢查詢日志輸出目標位置，可選值包括：TABLE，FILE，NONE；這些值可以任意組合，NONE的優先級最高
如果將設置log_output='table'，則通用查詢日志文件、慢查詢日志文件中只會保存系統啟動信息
general_log 系統變量：控制是否啟用通用日志
general_log_file 系統變量：控制通用日志文件
slow_query_log 系統變量：控制是否啟用慢查詢日志
slow_query_log_file 系統變量：控制慢查詢日志文件
注：如果將通用查詢日志和慢查詢日志存放在TABLE中，可以通過查詢mysql schema下的general_log表以及slow_log表獲取日志內容
關於日志表的一些補充：
寫到日志表中的條目不會寫到二進制日志文件中，所以也不會復制到 SLAVE Server
關於日志表清理方法：可以通過TRUNCAET TABLE語句清理，或者通過一個輪詢的方式，比如：
mysql > user mysql;
mysql> create table general_log2 like general_Log;
mysql> drop table general_log to gerneral_log_backup, gerneral_logs2 to general_log;
通過mysqldump命令只會dump日志表的定義，不會dump日志表中的數據，這樣在恢復時，可以保證恢復日志表結構
如果日志寫到文件當中，可以通過如下方式清理日志文件：
shell> mv host_name.log host_name-old.log
shell> mysqladmin flush-logs
shell> mv host_name-old.log backup-directory
也可以通過一種通用方式處理：
SET GLOBAL general_log = 'OFF';
shell> mv host_name.log host_name-old.log
SET GLOBAL general_log = 'ON';
在會話級啟停通用查詢日志，可以通過 sql_log_off 會話變量實現
寫在通用查詢日志中的密碼會被重寫，通過在MySQL Server啟動時添加 --log-raw 選項密碼不會重寫，這在排查問題時可能有用，但是不安全，生成中不建議使用
log_timestamps 系統變量：
這個系統變量影響通用查詢日志文件、慢查詢日志文件、錯誤日志的顯示時間戳，通過存儲在日志表中的日志時間戳顯示沒有影響
log_timestamps 系統變量有兩個取值：UTC、SYSTEM
錯誤日志：
錯誤日志包含：MySQL Server 啟停時間信息，以及在啟停和運行過程中的錯誤、警告、提示信息
如果使用mysqld_safe啟用MySQL Server，在mysqld異常終止時，mysqld_safe會重啟mysqld並把信息寫到錯誤日志中
在MySQL 8.0 中，錯誤日志子系統有執行log event過濾以及寫log event的組件和控制組件選擇的系統變量組成
log_error 系統變量：指定錯誤日志位置
log_error_verbosity 系統變量：指定錯誤日志記錄等級（0、1、2 分別對應 error、error warning、error warning note）
log_error_services 系統變量：指定過濾組件、寫組件
二進制日志：
二進制日志包含描述數據庫更改的 events，還包含每個更新語句花費的時間
二進制日志記錄對數據庫對象做出更改的語句，如果這個語句可能更改數據，比如：delete from table_name where 1=0;在二進制日志格式為STATEMENT時會記錄到二進制日志文件中，而二進制日志格式為ROW時則不會記錄到二進制日志文件中
二進制日志有兩個重要作用：
復制
恢復
二進制日志會對系統產生一些額外的開銷，如果MySQL Server不適用復制環境，或者不需要做時間點恢復的話，可以不用開啟二進制日志
與二進制日志相關系統變量：
log_bin 系統變量：指定二進制日志的basename
log_slave_updates 系統變量：這個系統變量應用在Slave Server中，在Slave Server應用從Master Server接收的二進制events時，是否將應用的events寫到Slave Server自身的二進制日志中
slave_preserve_commit_order 系統變量：這個系統變量也是在Slave Server中使用，而且是在多線程復制Slave Server才有意義
配置多線程復制Slave，設置 slave_parallel_workers 系統變量為非 0 值
可以將 slave_parallel_type 系統變量設置為 Logical Clock，這樣對於Master Server端組提交的事務可以在Slave Server端並行化應用接收的events
二進制日志刷新的幾種情形：
MySQL Server 啟動
flush logs
日志文件大小達到max_binlog_size 系統變量定義的值
注：二進制日志文件大小可能會超過 max_binlog_size 指定的大小，比如：一個大事務寫到日志文件，由於事務以 one piece 存儲到日志文件中，不會在日志文件中分割
log_bin_index 系統變量：查看二進制日志文件索引文件位置
sql_log_bin 會話變量：可以在會話級關閉二進制日志生成
驗證二進制日志完整性：
默認情況下，MySQL Server 會寫events和events長度用於驗證events是否正確寫入
如果 binlog_checksum 系統變量啟用，MySQL Server 還會寫入events校驗和
這樣在從二進制日志讀信息時，Master Server會使用events長度，以及校驗和信息（如果配置了master_verify_checksum 系統變量）
在Slave Server端，IO線程會驗證從Master Server端接收的events，如果Slave Server端配置了slave_sql_verify_checksum 系統變量，Slave Server的SQL線程也會驗證校驗和信息
在二進制日志中記錄的events的格式取決於二進制日志的格式，二進制日志格式包括：STATEMENT、ROW、MIX-BASED
可以通過 RESET MASTER命令刪除所有的二進制日志，或者通過 PURGE BINARY LOG語句刪除部分二進制日志
補充說明一下：
在復制環境中，在Master Server端，RESET MASTER不僅會刪除所有的二進制日志，如果使用的是基於GTID復制模式，也會清除所有的GTID信息；在Slave Server端，RESET SLAVE刪除所有中繼日志，RESET SLAVE ALL不僅會刪除所有中繼日志，而且會清除連接、狀態信息，在MySQL 8 中，默認使用mysql.slave_relay_log_info、mysql.slave_master_info表存儲有關信息
可以通過mysqlbinlog命令查看二進制日志內容，這是MySQL Server做時間點恢復會有用，比如：
shell> mysqlbinlog log_file | mysql -h server_name
對於事務表，在語句或者事務完成后，釋放鎖或者提交前，會立即記錄在二進制日志中
對於非事務表，在語句執行后，就會立即記錄在二進制日志中
在一個未提交的事務中，所有對支持事務表的更改，在Server未接收到提交之前會先進行緩存；提交后，在執行COMMIT前，MySQL Server將整個事務寫到二進制日志中
當一個線程開始處理事務時，會分配一個binlog_cache_size 系統變量的buffer用於buffer事務語句，如果事務語句大於binlog_cache_size 指定的值，線程打開一個臨時文件用於存儲該事務
binlog_cache_use 狀態變量：查看MySQL Server中使用binlog_cache這個buffer的事務數量（包括使用臨時文件的事務）
binlog_cache_disk_use 狀態變量：查看MySQL Server中使用臨時文件的事務
通過這兩個狀態變量，可以來調整binlog_cache_size值
MySQL Server中還定義了一個系統變量 max_binlog_cache_size用來限制整個Server中所有線程能夠使用的binlog buffer 大小
基於ROW格式的二進制日志，對於像CREATE ... SELECT 和 INSERT ... SELECT語句會將其轉化為一般的INSERT語句，這對於binlog_cache_size有一定的影響
binlog_error_action 系統變量：控制在寫、刷新、同步二進制日志時發生錯誤，MySQL Server所采取的動作，默認是：ABORT_SERVER，另外一個值是：IGNORE_ERROR，這個值用於向后兼容
sync_binlog 系統變量：控制通過二進制日志的頻率，默認值 1，是最安全的，但也是最慢的，與其相關的另一個系統變量：innodb_flush_log_at_trx_commit，默認值也是 1
早期MySQL Server存在的一種情況：
使用InnoDB表，MySQL處理事務，在將事務寫到二進制日志后，提交事務到InnoDB前，系統崩潰，重啟后，InnoDB回滾該事務，但是事務相關的日志保留在二進制日志文件中
早期解決這種情況的方法是使用XA事務，使InnoDB支持事務的兩階段提交，MySQL Server會截斷二進制日志到最后有效的位置
在MySQL 8.0以后總是啟用XA事務的兩階段提交，保證InnoDB 表數據與二進制日志數據一致
如果MySQL Server在崩潰恢復時發現二進制日志比他應該的大小下的時候，它丟失了至少一個成功提交的事務；在這種情況下，二進制日志是不正確的，復制應該從Master Server 新的快照中開始；
這種情況不會發生，如果sync_binlog=1並且二進制日志真的同步到磁盤上（有時不會）
sync_binlog=1: Enables synchronization of the binary log to disk before transactions are committed. This is the safest setting but can have a negative impact on performance due to the increased number of disk writes. In the event of a power failure or operating system crash, transactions that are missing from the binary log are only in a prepared state. This permits the automatic recovery routine to roll back the transactions, which guarantees that no transaction is lost from the binary log.
二進制日志格式：
binlog_format 系統變量：可選值：STATEMENT、ROW、MIXED
基於MIXED的二進制日志格式默認使用基於STATEMENT二進制日志格式
在復制模式下，主從節點的binglog_format應該保持一致
在使用InnoDB存儲引擎，同時事務隔離等級時READ-COMMITTED情況下，將BINLOG_FORMAT設置為STATEMENT，會導致InnoDB表不能插入數據
binlog_row_event_max_size 系統變量：
Where possible, rows stored in the binary log are grouped into events with a size not exceeding the value of this setting. If an event cannot be split, the maximum size can be exceeded.
慢查詢日志：
The server uses the controlling parameters in the following order to determine whether to write a query to the slow query log:
1. The query must either not be an administrative statement, or log_slow_admin_statements must be enabled.
2. The query must have taken at least long_query_time seconds, or log_queries_not_using_indexes must be enabled and the query used no indexes for row lookups.
3. The query must have examined at least min_examined_row_limit rows.
4. The query must not be suppressed according to the log_throttle_queries_not_using_indexes setting.
MySQL 8.0.14 版本之后在使用慢查詢日志文件時，可以設置log_slow_extra 系統變量，會在慢查詢日志文件中多出一些額外字段信息，
慢查詢日志文件中的SET語句，指定一個時間戳，在MySQL 8.0.14版本之前是指語句寫入日志文件的時間，在MySQL 8.0.14 版本之后指語句開始執行時間
DDL日志：
DDL日志是為了維護DDL操作的原子性，DDL日志會在需要時，生成在數據目錄下：ddl_log.log
一般是不需要人為干預該日志文件，除非該日志文件達到上限，4G
Server 日志維護：
在Linux（RedHat）安裝上，可以使用mysql-log-rotate腳本做日志維護
在其它系統上，可以通過cron調用腳本的方式做日志維護工作
binlog_expire_logs_seconds：控制二進制日志過期天數，默認是30天，刪除過期二進制日志文件發生在Server 啟動，或者刷新二進制日志文件；如果是在復制環境中使用該參數，注意該值不能小於Slave落后Master的最大時間
強制MySQL使用新的日志文件：FLUSH LOGS、MYSQLADMIN FLUSH-LOGS、MYSQLADMIN REFRESH、MYSQLDUMP --LFUSH-LOGS
FLUSH LOGS命令支持選擇特定的待刷新的日志文件，比如：FLUSH BINARY LOGS
這樣如果是要使用新的通用日志文件、慢查詢日志文件、錯誤日志文件，在類-Unix平台上可以這樣實現：
cd mysql-data-directory
mv mysql.log mysql.log.old
mv mysql-slow.log mysql-slow.log.old
mv err.log err.log.old
flush general logs;
flush slow logs;
flush error logs;
而不會對其他日志文件有影響
補充說明一下：
通過重命名日志文件的方式刷新日志文件，要注意MySQL Server要有新生成的日志文件目錄的寫入權限
通過FLUSH 命令刷新需要連接到MySQL Server，其實通過信號也可以刷新日志文件，在MySQL 8.0.19版本，可以通過SIGUSR1只同時刷新通用日志文件、慢查詢日志文件、錯誤日志文件