Mysql中，日誌可以按照功能分爲：
錯誤日誌
查詢日誌
慢查詢日誌
二進制日誌
中繼日誌
innodb存儲引擎級別的事務日誌
1. 錯誤日誌
錯誤日誌中記錄了mysql執行過程中的錯誤信息，但是其不僅僅記錄了執行過程中的錯誤信息，還會記錄其他信息，錯誤日誌會記錄如下信息：
mysql執行過程中的錯誤信息
mysql執行過程中的警告信息
event scheduler運行時所產生的信息
mysql啓動和停止過程中的輸出信息，未必是錯誤信息
主從複製結構中，從服務器IO複製線程的啓動信息
mysql中，錯誤日誌使用log_error以及log_warnings等參數進行定義。
log_warnings用於標識警告信息是否一併記錄到錯誤日誌中。
log_warnings的值爲0，表示不記錄警告信息。
log_warnings的值爲1，表示警告信息一併記錄到錯誤日誌中。
log_warnings的值大於1，表示"失敗的連接"的信息和創建新連接時"拒絕訪問"類的錯誤信息也會被記錄到錯誤日誌中。
mysql> show variables like '%log_error%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_error | |
+---------------+-------+
1 row in set (0.00 sec)
mysql> show variables like '%log_warning%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_warnings | 2 |
+---------------+-------+
1 row in set (0.00 sec)
2. 查詢日誌
查詢日誌在mysql中被稱之爲general log（通用日誌），不要被"查詢日誌"的名字誤導，錯誤的以爲查詢日誌只會記錄select語句，其實不然，查詢日誌記錄了數據庫執行的命令，不管這些 語句是否正確，都會被記錄，當開啓了查詢日誌以後，數據庫可能需要不停的寫入查詢日誌，這樣會 增大服務器的IO壓力，增加很多系統開銷，所以默認情況下，mysql的查詢日誌是沒有開啓的，但是開啓查詢日誌也有助於分析哪些語句執行密集，執行 密集的select語句對應的數據是否能夠被緩存，查詢日誌也可以幫助分析問題，所以，可以根據實際情況決定是否開啓查詢日誌，如果需要可以手動 開啓。如果開啓了查詢日誌，那麼可以通過如下3種方式存儲查詢日誌。
方式1：將查詢日誌存放於指定的日誌文件中。
方式2：將查詢日誌存放於mysql.general_log表中。
方式3：將查詢日誌同時存放於指定的日誌文件與mysql庫的general_log表中。
mysql> show variables where variable_name like "%general_log%" or variable_name="log_output";
+------------------+------------+
| Variable_name | Value |
+------------------+------------+
| general_log | OFF |
| general_log_file | master.log |
| log_output | FILE |
+------------------+------------+
3 rows in set (0.00 sec)
log_output可以設置爲4種 值，“FILE”、“TABLE”、“FILE,TABLE”、“NONE”。此值爲"FILE"表示存放於指定的文件中，此值爲"TABLE"表示存放 於mysql庫的general_log表中，此值爲"FILE,TABLE"表示將查詢日誌同時存放於指定的文件與general_log表中，一般不 會進行這樣的設置，因爲這樣會徒增很多IO壓力，如果開啓，建議設置爲"table",此值爲"NONE"時表示不記錄查詢日誌，即使 general_log設置爲ON，如果log_output設置爲NONE，也不會記錄查詢日誌，其實，log_output不止用戶控制查詢日誌的輸 出，慢查詢日誌的輸出也是由此參數進行控制，也就是說，log_output設置爲file，就表示查詢日誌和慢查詢日誌都存放到對應的文件中，設置爲 table，查詢日誌和慢查詢日誌就都存放在對應的數據庫表中。
general_log_file:表示當log_output的值設置爲"FILE"或者"FILE,TABLE"時，將查詢日誌存放於哪個日誌 文件中，換句話說，就是通過此參數指定查詢日誌的文件，默認情況下，此文件名於主機名相同，而且使用了相對路徑，默認位置爲datadir變量所對應的目 錄位置，一般爲/var/lib/mysql目錄下。
mysql> show variables where variable_name like "%general_log%" or variable_name="log_output";
+------------------+------------+
| Variable_name | Value |
+------------------+------------+
| general_log | OFF |
| general_log_file | master.log |
| log_output | FILE |
+------------------+------------+
3 rows in set (0.00 sec)
mysql> set global general_log=on;
Query OK, 0 rows affected (0.00 sec)
mysql> set global log_output='FILE,TABLE'
-> ;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables where variable_name like "%general_log%" or variable_name="log_output";
+------------------+------------+
| Variable_name | Value |
+------------------+------------+
| general_log | ON |
| general_log_file | master.log |
| log_output | FILE,TABLE |
+------------------+------------+
3 rows in set (0.01 sec)
[root@master ~]# cat /var/lib/mysql/master.log
/usr/sbin/mysqld, Version: 10.2.31-MariaDB (MariaDB Server). started with:
Tcp port: 3306 Unix socket: /var/lib/mysql/mysql.sock
Time Id Command Argument
200328 22:55:13 20 Query set global log_output=FILE,TABLE
200328 22:55:23 20 Query set global log_output='FILE,TABLE'
200328 22:55:57 20 Query show variables where variable_name like "%general_log%" or variable_name="log_output"
200328 22:56:37 19 Quit
mysql> select * from mysql.general_log \G;
*************************** 1. row ***************************
event_time: 2020-03-28 22:55:57.029412
user_host: root[root] @ node1 [192.168.1.72]
thread_id: 20
server_id: 1
..............
3. 二進制日誌
二進制日誌爲binlog，它記錄了所有修改了數據庫的語句，或者有可能會改變數據庫的語句，select、show類不修改數據庫的操作，二進制日誌是不會進行記錄的，二進制日誌主要用於時間點恢復（備份恢復），以及主從複製結構。
binlog記錄了所有的修改了數據庫的語句，那麼，來想一個問題，假設，在執行某 條修改數據庫的語句時，用到了user()函數，那麼當執行這條語句時，語句根據當前用戶的信息修改了數據庫，然後這條語句將被記錄到binlog 中，但是，語句被記錄在binlog中時，並沒有記錄當前用戶的信息，而是記錄了"user()“這個函數本身的幾個字符，當根據binlog再次重 放這條語句時，如果重放這條語句的用戶與這條語句被記錄時所使用的用戶不同，那麼語句執行後的結果就不同，這樣就導致根據binlog重放操作時，並不能 得到與預想的完全一致的數據，這種情況在數據恢復時是不允許的，在主從複製時也不是期望看到的，所以，爲了能夠完全的還原日誌被記錄時的操作，我 們應該記錄對應語句到底修改了哪些行，並且記錄對應語句對這些行進行了哪些修改，只有這樣，才能保證在重放binlog時，執行的操作與記錄日誌時的 操作是完全一致的，這樣是安全了，但是，設想一下，如果執行了一條update語句，這條update語句涉及到10000行數據的修改，那麼， 就需要將這條sql涉及到的10000行數據修改都記錄到binlog中，以便重放二進制日誌時，能夠還原當時的操作，這樣與只記錄一條update 語句來說，記錄的信息量就大的多了，這樣想想，這兩種記錄方式還是各有優勢的。當然，到底是讓binlog以記錄語句的模式進行記錄，還是以記錄數據修改 的模式進行記錄，這些都是數據庫管理員可以決定的，可以設置mysql通過哪種模式記錄binlog，mysql中，有三種模 式，statement、row、mixed，來總結一下binlog的這三種記錄模式。
二進制日誌有3種記錄方式，三種方式：
statement模式：記錄對數據庫做出修改的語句，比如，update A set test=‘test’,如果使用statement模式，那麼這條update語句將會被記錄到二進制日誌中，使用statement模式時，優點是 binlog日誌量少，IO壓力小，性能較高，缺點是爲了能夠儘量的完全一致的還原操作，除了記錄語句本身以外，可能還需要記錄一些相關的信息，而且，在 使用一些特定的函數時，並不能保證恢復操作與記錄時完全一致。
row模式：記錄對數據庫做出修改的語句所影響到的數據行以及這些行的修改，比如，update A set test=‘test’，如果使用row模式，那麼這條update語句所影響到的行所對應的修改，將會記錄到binlog中，比如，A表中有1000條 數據，那麼當執行這條update語句以後，由於1000條數據都會被修改，所以會有1000行數據被記錄到二進制日誌中，以及它們是怎樣被修改的，使用 row模式時，優點是能夠完全的還原或者複製日誌被記錄時的操作，缺點是記錄日誌量較大，IO壓力大，性能消耗較大。
mixed模式：混合使用上述兩種模式，一般的語句使用statment方式進行保存，如果遇到一些特殊的函數，則使用row模式進行記錄，這種記錄方式被稱之爲mixed，看上去這種方式似乎比較美好，但是在生產環境中，爲了保險起見，一般會使用row模式。
使用binlog_format變量設置二進制日誌的記錄方式，爲了使配置永久生效，可以在my.cnf配置文件中加入配置。
binlog_format=row
二進制日誌文件， 有"事件"和"位置"的概念，什麼是事件呢？通俗的講，可以把binlog中的每一條記錄當做一個"事件”，因爲binlog記錄了所有對數據庫進行 的修改，所以，可以認爲，數據庫的修改被記錄到二進制日誌中，記錄每一條都可以理解爲一個"事件"，由於二進制日誌文件是二進制的，所以，可 以把整個二進制文件想象成一個字節序列，假設，二進制日誌文件剛開始是空的，從第1個字節開始記錄，假設記錄第一個"事件"（第一條記錄），需要15個字 節，那麼第一個事件的開始"位置"就是1，結束"位置"就是15，由於前15個字節已經被第一個事件佔用，那麼當想要通過二進制日誌記錄第二個事件 時，則需要從第15個字節向後開始記錄，假設記錄第二個"事件"需要20個字節，那麼第二個事件在binlog中的起始"位置"就是15，結束"位置"就 是35，以此類推，這就是二進制日誌中，"事件"與"位置"的概念，"事件"被稱爲events，"位置"被稱爲position。
二進制日誌相關參數
mysql> show variables like '%log_bin%';
+---------------------------------+-------+
| Variable_name | Value |
+---------------------------------+-------+
| log_bin | OFF |
| log_bin_basename | |
| log_bin_index | |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| sql_log_bin | ON |
+---------------------------------+-------+
log_bin : 此變量用於控制是否開啓二進制日誌，只讀變量，只能在my.cnf中配置，不能使用set配置，配置該變量包括兩個操作，啓動二進制日誌和設置二進制日誌的文件名，設置log_bin的值爲mybinlog，那麼，在mysql的數據目錄中，將會自動生成一個以mybinlog爲文件名前綴的二進 制日誌文件，禁用binlog，需將log_bin這一行配置從my.cnf文件中註釋或其刪除，重啓mysql服務，再次 查看log_bin的值，其值爲OFF，不要直接在my.cnf文件中將log_bin的值設置爲ON或者OFF，如果這樣做，你將會看到以ON或 者OFF爲文件名前綴的二進制日誌文件，二進制日誌文件的後綴 名會進行自動編號，每次日誌滾動後，後綴名編號自動加1。
sql_log_bin ：用於標識當前會話中的操作是否會被記錄於二進制日誌，此變量值設置爲ON，則表示在當前數據庫連接中，對數據庫進行修改的語句將會被記錄到 binlog中，此變量值設置爲OFF，則表示在當前數據庫連接中，對數據庫進行的修改的語句將不會被記錄到binlog中，在主從複製結構中，這些語句 由於沒有被binlog記錄，所以也不會同步到從節點中。換句話說，即使在my.cnf配置文件中設置了log_bin的值，當前會話中，如果 sql_log_bin的值設置爲OFF，當前會話的操作也不會記錄在二進制日誌中。sql_log_bin是一個會話界別的變量，只 能在當前會話中使用set sql_log_bin命令進行設置，不能使用set global sql_log_bin命令進行設置，因爲它是會話級別的變量，sql_log_bin也不能配置在my.cnf文件中，可能會無法啓動 mysql。
binlog_format ： 二進制日誌的記錄方式，此變量的值可以設置爲statement、row、mixed，分別表示以語句的 形式記錄二進制日誌，以數據修改的形式記錄二進制日誌，以混合的方式記錄二進制日誌，安全保險起見，推薦使用row的方式記錄。
max_binlog_size ：設置單個二進制日誌文件的最大大小，以字節爲單位，超過此值大小，則二進制日誌文件會自動滾動，比如設置爲500M爲524288000。
sync_binlog ：將sync_binlog爲1，每次事務提交之後，會立即將內存中的二進制日誌立即同步到磁盤中的二進制日誌文件中，值爲0時，一旦操作系統宕機，那麼將丟失未從內存中同步到磁盤中的binlog，值爲0時，安全性最差，但性能最高，值爲1，安全性最高，性能最差，除了設置爲0或1，還能設置爲N，示每N次事務提交後，將binlog從內存刷寫到磁盤一次，值越大，有可能丟失的日誌數據將會越多，當然，性能會越好，在追求安全的情況下，推薦設 置爲1，但是聽說，此值設置爲0和設置爲1時在性能上的差距還是比較明顯的，如果設置爲0或N，最好爲操作系統準備帶有備用電源的緩存。
[root@master ~]# vim /etc/my.cnf
[mysqld]
log_bin=mysql_log;
binlog_format=row
[root@master ~]# systemctl restart mariadb
[root@master ~]# mysql -uroot -p
MariaDB [(none)]> show binary logs;
+-------------------+-----------+
| Log_name | File_size |
+-------------------+-----------+
| mysql_log;.000001 | 329 |
+-------------------+-----------+
MariaDB [(none)]> show master logs;
+-------------------+-----------+
| Log_name | File_size |
+-------------------+-----------+
| mysql_log;.000001 | 329 |
+-------------------+-----------+
1 row in set (0.00 sec)
MariaDB [(none)]> show binlog events;
+-------------------+-----+-------------------+-----------+-------------+------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+-------------------+-----+-------------------+-----------+-------------+------------------------------------------------+
| mysql_log;.000001 | 4 | Format_desc | 1 | 256 | Server ver: 10.2.31-MariaDB-log, Binlog ver: 4 |
| mysql_log;.000001 | 256 | Gtid_list | 1 | 285 | [] |
| mysql_log;.000001 | 285 | Binlog_checkpoint | 1 | 329 | mysql_log;.000001 |
+-------------------+-----+-------------------+-----------+-------------+------------------------------------------------+
3 rows in set (0.00 sec)
MariaDB [(none)]> show binlog events in 'mysql_log;.000001';
+-------------------+-----+-------------------+-----------+-------------+------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+-------------------+-----+-------------------+-----------+-------------+------------------------------------------------+
| mysql_log;.000001 | 4 | Format_desc | 1 | 256 | Server ver: 10.2.31-MariaDB-log, Binlog ver: 4 |
| mysql_log;.000001 | 256 | Gtid_list | 1 | 285 | [] |
| mysql_log;.000001 | 285 | Binlog_checkpoint | 1 | 329 | mysql_log;.000001 |
+-------------------+-----+-------------------+-----------+-------------+------------------------------------------------+
3 rows in set (0.00 sec)
MariaDB [(none)]> show binlog events in 'mysql_log;.000001' from 4;
+-------------------+-----+-------------------+-----------+-------------+------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+-------------------+-----+-------------------+-----------+-------------+------------------------------------------------+
| mysql_log;.000001 | 4 | Format_desc | 1 | 256 | Server ver: 10.2.31-MariaDB-log, Binlog ver: 4 |
| mysql_log;.000001 | 256 | Gtid_list | 1 | 285 | [] |
| mysql_log;.000001 | 285 | Binlog_checkpoint | 1 | 329 | mysql_log;.000001 |
+-------------------+-----+-------------------+-----------+-------------+------------------------------------------------+
3 rows in set (0.00 sec)
MariaDB [(none)]> show binlog events in 'mysql_log;.000001' from 256;
+-------------------+-----+-------------------+-----------+-------------+-------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+-------------------+-----+-------------------+-----------+-------------+-------------------+
| mysql_log;.000001 | 256 | Gtid_list | 1 | 285 | [] |
| mysql_log;.000001 | 285 | Binlog_checkpoint | 1 | 329 | mysql_log;.000001 |
+-------------------+-----+-------------------+-----------+-------------+-------------------+
2 rows in set (0.00 sec)
MariaDB [(none)]> show binlog events in 'mysql_log;.000001' limit 2;
+-------------------+-----+-------------+-----------+-------------+------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+-------------------+-----+-------------+-----------+-------------+------------------------------------------------+
| mysql_log;.000001 | 4 | Format_desc | 1 | 256 | Server ver: 10.2.31-MariaDB-log, Binlog ver: 4 |
| mysql_log;.000001 | 256 | Gtid_list | 1 | 285 | [] |
+-------------------+-----+-------------+-----------+-------------+------------------------------------------------+
2 rows in set (0.00 sec)
MariaDB [(none)]> show binlog events in 'mysql_log;.000001' limit 1, 2;
+-------------------+-----+-------------------+-----------+-------------+-------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+-------------------+-----+-------------------+-----------+-------------+-------------------+
| mysql_log;.000001 | 256 | Gtid_list | 1 | 285 | [] |
| mysql_log;.000001 | 285 | Binlog_checkpoint | 1 | 329 | mysql_log;.000001 |
+-------------------+-----+-------------------+-----------+-------------+-------------------+
2 rows in set (0.00 sec)
顯示當前log記錄在哪個位置上
MariaDB [(none)]> show master status;
+-------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+------------------+
| mysql_log;.000001 | 329 | | |
+-------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
手動切換，使下一個日誌文件
MariaDB [(none)]> flush logs;
Query OK, 0 rows affected (0.02 sec)
MariaDB [(none)]> show master status;
+-------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+------------------+
| mysql_log;.000002 | 373 | | |
+-------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
記錄所使用的日誌文件
[root@master mysql]# pwd
/var/lib/mysql
[root@master mysql]# cat mysql_log\;.index
./mysql_log;.000001
./mysql_log;.000002
4. mysqlbinlog
查看對應的二進制日誌
[root@master mysql]# mysqlbinlog mysql_log\;.000001
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#200329 8:53:27 server id 1 end_log_pos 256 CRC32 0x7b7c8e5a Start: binlog v 4, server v 10.2.31-MariaDB-log created 200329 8:53:27 at startup
ROLLBACK/*!*/;
BINLOG '
h/F/Xg8BAAAA/AAAAAABAAAAAAQAMTAuMi4zMS1NYXJpYURCLWxvZwAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAACH8X9eEzgNAAgAEgAEBAQEEgAA5AAEGggAAAAICAgCAAAACgoKAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAEEwQADQgICAoKCgFajnx7
'/*!*/;
# at 256
#200329 8:53:27 server id 1 end_log_pos 285 CRC32 0x3e483b8a Gtid list []
# at 285
#200329 8:53:27 server id 1 end_log_pos 329 CRC32 0x7c2959c0 Binlog checkpoint mysql_log;.000001
# at 329
#200329 9:01:57 server id 1 end_log_pos 377 CRC32 0x61d6bfef Rotate to mysql_log;.000002 pos: 4
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
[root@master mysql]# mysqlbinlog mysql_log\;.000001 --start-position 4
[root@master mysql]#mysqlbinlog --start-position 317 --stop-position 442 mybinlog.000001
[root@master mysql]#mysqlbinlog --start-datetime "2017-3-4 10:40:00" mybinlog.000001;
[root@master mysql]#mysqlbinlog --start-datetime "2017-3-4 10:40:00" --stop-datetime "2017-3-4 10:55:00" mybinlog.000001;
5. 慢查詢日誌
MariaDB [(none)]> show variables like '%slow_query%';
+---------------------+-----------------+
| Variable_name | Value |
+---------------------+-----------------+
| slow_query_log | OFF |
| slow_query_log_file | master-slow.log |
+---------------------+-----------------+
2 rows in set (0.00 sec)
某些sql語句執行完畢所花費的時間特別長，將這種響應比較慢的語句記錄在慢查詢日誌中，不要被"慢查詢日誌"的名字誤導，錯誤的以爲慢查詢日 志只會記錄執行比較慢的SELECT語句，其實不然，INSERT、DELETE、UPDATE、CALL等DML操作，只要是超過了指定的時間，都可以 稱之爲"慢查詢"，被記錄在慢查詢日誌中。聰明如你一定已經想到了，“慢查詢日誌"與"查詢日誌"的理念很像。默認情況下，慢查詢日誌是不被開啓的，如果 需要，可以手動開啓，開啓慢查詢日誌之後，默認設置下，執行超過10秒的語句纔會被記錄到慢查詢日誌中，當然，對於"慢"的定義，可以自定義。
log_slow_queries ：表示是否開啓慢查詢日誌，5.6以前的版本使用此參數指定是否 開啓慢查詢日誌，5.6以後的版本使用slow_query_log取代此參數，如果你使用的mysql版本剛好是5.5，那麼你可以看到這兩個參數同時 存在，此時不用同時設置它們，設置這兩個參數中的任何一個，另一個也會自動保持一致。
log_output : 表示當慢查詢日誌開啓以後，以哪種方式存放，log_output可以設置爲4種 值，“FILE”、“TABLE”、“FILE,TABLE”、“NONE”。此值爲"FILE"表示慢查詢日誌存放於指定的文件中，此值 爲"TABLE"表示慢查詢日誌存放於mysql庫的slow_log表中，此值爲"FILE,TABLE"表示將慢查詢日誌同時存放於指定的文件與 slow_log表中，一般不會進行這樣的設置，因爲這樣會徒增很多IO壓力，如果開啓，建議設置爲"table”,此值爲"NONE"時表示不記錄查詢 日誌，即使slow_query_log設置爲ON，如果log_output設置爲NONE，也不會記錄慢查詢日誌，其實，log_output不止用 於控制慢查詢日誌的輸出，查詢日誌的輸出也是由此參數進行控制，也就是說，log_output設置爲file，就表示查詢日誌和慢查詢日誌都存放到對應 的文件中，設置爲table，查詢日誌和慢查詢日誌就都存放在對應的數據庫表中。
slow_query_log ：表示是否開啓慢查詢日誌，此參數與log_slow_queries的作用沒有區別，5.6以後的版本使用此參數替代log_slow_queries。
slow_query_log_file ：當使用文件存儲慢查詢日誌時(log_output設置 爲"FILE"或者"FILE,TABLE"時)，指定慢查詢日誌存儲於哪個日誌文件中，默認的慢查詢日誌文件名爲"主機名-slow.log"，慢查詢 日誌的位置爲datadir參數所對應的目錄位置，一般情況下爲 /var/lib/mysql
long_query_time ：表示"多長時間的查詢"被認定爲"慢查詢"，此值得默認值爲10秒，表示超過10秒的查詢被認定爲慢查詢。
log_queries_not_using_indexes ：表示如果運行的sql語句沒有使用到索引，是否也被當做慢查詢語句記錄到慢查詢日誌中，OFF表示不記錄，ON表示記錄。
log_throttle_queries_not_using_indexes ：5.6.5版本新引入的參數，當log_queries_not_using_inde設置爲ON時，沒有使用索引的查詢語句也會被當做慢查詢語句記錄 到慢查詢日誌中，使用log_throttle_queries_not_using_indexes可以限制這種語句每分鐘記錄到慢查詢日誌中的次數， 因爲在生產環境中，有可能有很多沒有使用索引的語句，此類語句頻繁的被記錄到慢查詢日誌中，可能會導致慢查詢日誌快速不斷的增長，管理員可以通過此參數進 行控制。
MariaDB [(none)]> set global slow_query_log=on;
Query OK, 0 rows affected (0.01 sec)
MariaDB [(none)]> select @@global.long_query_time;
+--------------------------+
| @@global.long_query_time |
+--------------------------+
| 10.000000 |
+--------------------------+
1 row in set (0.01 sec)
MariaDB [(none)]> set global long_query_time=3;
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> select @@long_query_time;
+-------------------+
| @@long_query_time |
+-------------------+
| 3.000000 |
+-------------------+
1 row in set (0.00 sec)
MariaDB [(none)]> show variables where variable_name like '%slow_query%' or variable_name='log_output';
+---------------------+-----------------+
| Variable_name | Value |
+---------------------+-----------------+
| log_output | FILE |
| slow_query_log | ON |
| slow_query_log_file | master-slow.log |
+---------------------+-----------------+
顯示共有多少條慢查詢
MariaDB [(none)]> show global status like ‘%slow_queries%’;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Slow_queries | 1 |
+---------------+-------+
1 row in set (0.00 sec)
6. mysqldumpslow
mysqldumpslow命令從不同的維度對 慢日誌進行排序、查找、統計。但是mysqldumpslow只能作用於慢查詢日誌文件，不統計slow_log表，將log_output的值設置爲"FILE"或 者"FILE,TABLE"時，可以通過mysqldumpslow查看對應的慢查詢日誌文件。
-s選項代表排序，-s選項後添加的參數：
c: 執行計數
l: 鎖定時間
r: 返回記錄
t: 執行時間
al:平均鎖定時間
ar:平均返回記錄數
at:平均執行時間
根據統計數量進行排序
根據記錄數進行排序
指定顯示的記錄條數
指定正則
————Blueicex 2020/3/29 09:30 [email protected]