MySQL日誌記錄了MySQL數據庫日常操作和錯誤信息。MySQL有不同類型的日誌文件（各自存儲了不同類型的日誌），從日誌當中可以查詢到MySQL數據庫的運行情況、用戶的操作、錯誤的信息等。
MySQL的日誌分爲以下四大類：
錯誤日誌：記錄mysql服務的啓動，運行或停止mysql服務時出現的問題；
查詢日誌：記錄建立的客戶端的連接和執行的語句；
二進制日誌：記錄所有更改數據的語句，可以用於數據的複製；
慢查詢日誌：記錄所有執行的時間超過long_query_time的所有查詢或不使用索引的查詢；
默認情況下，所有日誌創建於MySQL數據目錄中，通過刷新日誌，可以強制MySQL關閉和重新打開日誌文件，Flush logs刷新日誌或者執行mysqladmin flush-logs 如果正使用MySQL複製功能，在複製服務器上可以維護更多日誌文件，這種日誌我們稱爲接替日誌。啓動日誌功能會降低MySQL數據庫的性能。
1）查看系統設置
#查看全局的系統狀態
mysql> show global variables\G
mysql> show global variables like '%log%';
#查看當前會話的系統狀態
mysql> show session variables\G
mysql> show session variables like '%log%';
若要修改上面查看出來的參數，可以在MySQL的主配置文件中的mysqld字段中寫入即可，如：binlog_cache_size = 1M。又或者可以在MySQL數據庫中進行臨時修改：set global binlog_cache_size = 1048576，這種臨時修改在MySQL重啓後就會失效。
2）查看運行狀態
#查看全局的運行狀態=
mysql> show global status\G
#查看當前會話的運行狀態
mysql> show session status;
#查看MySQL的版本
[root@mysql ~]# mysql -V
mysql> status;
mysql> select version();1、錯誤日誌
在mysql數據庫中，錯誤日誌功能是默認開啓的。默認情況下，錯誤日誌存儲在mysql數據庫的數據目錄中。錯誤日誌文件通常的名稱爲hostname.err。其中，hostname表示服務器主機名。 錯誤日誌信息可以自己進行配置的，錯誤日誌所記錄的信息是可以通過log-error和log-warnings來定義的，其中log-error是定義是否啓用錯誤日誌的功能和錯誤日誌的存儲位置，log-warnings是定義是否將警告信息也定義至錯誤日誌中。默認情況下錯誤日誌大概記錄以下幾個方面的信息：服務器啓動和關閉過程中的信息（未必是錯誤信息，如mysql如何啓動InnoDB的表空間文件的、如何初始化自己的存儲引擎的等等）、服務器運行過程中的錯誤信息、事件調度器運行一個事件時產生的信息、在從服務器上啓動服務器進程時產生的信息，MySQL有很多系統變量可以設置，系統變量設置不同，會導致系統運行狀態的不同。因此mysql提供兩組命令，分別查看系統設置和運行狀態。
一般而言，日誌級別的定義沒有會話變量都只是在全局級別下定義錯誤日誌的狀態：
mysql> show global variables like '%log_error%';
+---------------------+---------------------------------+
| Variable_name | Value |
+---------------------+---------------------------------+
| binlog_error_action | ABORT_SERVER |
| log_error | /usr/local/mysql/data/mysql.err |
| log_error_verbosity | 3 |
+---------------------+---------------------------------+
3 rows in set (0.00 sec)其中 log_error定義爲錯誤日誌文件路徑 ，log_error_verbosity值得含義如下:
| Verbosity | Message |
|---|---|
| 1 | Error only |
| 2 | Error and warnings |
| 3 | Errors, warnings,and notes(default) |
錯誤日誌的存放路徑在my.cnf的主配置文件中指定，如下：
[root@mysql ~]# cat /etc/my.cnf
[client]
socket=/usr/local/mysql/mysql.sock
[mysqld]
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
pid-file=/usr/local/mysql/data/mysql.pid
socket=/usr/local/mysql/mysql.sock
log-error=/usr/local/mysql/data/mysql.err # 此行定義錯誤日誌位置
爲了方便維護需要，有時候會希望將錯誤日誌中的內容做備份並重新開始記錄，這時候就可以利用MySQL 的FLUSH LOGS 命令來告訴MySQL 備份舊日誌文件並生成新的日誌文件。備份文件名以“.old”結尾。
刪除錯誤日誌
在mysql5.5.7之前：數據庫管理員可以刪除很長時間之前的錯誤日誌，以保證mysql服務器上的硬盤空間。mysql數據庫中，可以使用mysqladmin命令開啓新的錯誤日誌。mysqladmin命令的語法如下：mysqladmin –u root –p flush-logs也可以登錄mysql數據庫中使用FLUSH LOGS語句來開啓新的錯誤日誌。 在mysql5.5.7之後：服務器將關閉此項功能。只能使用重命名原來的錯誤日誌文件，手動沖洗日誌創建一個新的，方式如下：
[root@mysql ~]# cd /usr/local/mysql/data/
[root@mysql data]# mv mysql.err{,.old}
[root@mysql data]# mysqladmin -uroot -p flush-logs
Enter password:
#再次ls查看就會有一個新的mysql.err 文件誕生2、二進制日誌
二進制日誌主要記錄MySQL數據庫的變化，二進制日誌以一種有效的格式，並且是事務安全的方式包含更新日誌中可用的信息。二進制日誌包含了所有更新了數據或者已經潛在更新了數據。還包含關於每個更新數據庫的語句的執行時間，它不包含沒有修改任何數據的語句。使用二進制日誌的主要目的是最大可能地恢復數據庫。
1）啓動二進制日誌（默認情況下二進制日誌是關閉的）
[root@mysql ~]# vim /etc/my.cnf
[mysqld]
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
pid-file=/usr/local/mysql/data/mysql.pid
socket=/usr/local/mysql/mysql.sock
log-error=/usr/local/mysql/data/mysql.err
port=3306
server_id=1
log-bin=/usr/local/mysql/data/binary_log #指定二進制日誌的路徑及名稱
expire_logs_days=10 #清除日誌的天數
max_binlog_size=100M #單個日誌文件的大小限制，超出會新建一個日誌文件
[root@mysql ~]# systemctl restart mysqld
[root@mysql ~]# ll /usr/local/mysql/data/ | grep binary
-rw-r----- 1 mysql mysql 154 May 20 15:57 binary_log.000001
-rw-r----- 1 mysql mysql 40 May 20 15:57 binary_log.index注：在開啓二進制日誌時需要在my.cnf中指定server_id，否則回啓動失敗，日誌文件中也只是會報一個警告，而不會報錯
登錄到數據庫中也可以查看到，如下：
2）查看二進制日誌
MySQL二進制日誌存儲了所有的變更信息，MySQL二進制日誌經常使用。當MySQL創建二進制日誌文件時，首先創建一個以’filename’爲名稱，以’.index’爲後綴的文件；在創建一個以’filename’爲名稱，以’.000001’爲後綴的文件。當MySQL服務重啓一次，以’.000001’爲後綴的文件會增加一個，並且後綴名加1
遞增。如果日誌長度超過max_binlog_size的上限，也會創建一個新的日誌。 Show binary logs;可以查看當前的二進制日誌文件個數及其文件名。
二進制日誌並不能直接查看，如果想要查看日誌內容，可以通過mysqlbinlog命令查看：
mysql> show binary logs;
+-------------------+-----------+
| Log_name | File_size |
+-------------------+-----------+
| binary_log.000001 | 154 |
+-------------------+-----------+
1 row in set (0.00 sec)也可以退出MySQL在命令行使用mysqlbinlog命令查看：
[root@mysql data]# mysqlbinlog binary_log.000001 3）刪除二進制日誌
MySQL的二進制文件可以配置自動刪除，同時MySQL提供了手動刪除二進制文件的方法：
RESET MASTER：刪除所有的二進制日誌文件；
PURGE MASTER LOGS：只刪除部分二進制日誌文件；
Reset master：刪除所有二進制日誌 ；
Purge master logs to ‘二進制名’ ：刪除單個二進制日誌之前的。
mysql> purge master logs to "binary_log.000003"; #刪除...03之前的二進制日誌文件
mysql> purge master logs before '20180101'; #刪除2018-01-01之前的日誌文件4）通過二進制日誌還原MySQL數據
參考博文：MySQL的備份與恢復詳解請添加鏈接描述
3、事務日誌
事務日誌（InnoDB特有的日誌，因爲只有Innodb支持事務）可以幫助提高事務的效率。使用事務日誌，存儲引擎在修改表的數據時只需要修改其內存拷貝，再把修改行爲記錄到持久在硬盤上的事務日誌中，而不用每次都將修改的數據本身持久到磁盤。事務日誌採用追加的方式，因此寫日誌的操作是磁盤上一小塊區域內的順序I/O，而不像隨機I/O需要在磁盤的多個地方移動磁頭，所以採用事務日誌的方式相對來說要快得多。事務日誌持久以後，內存中被修改的數據在後臺可以慢慢的刷回到磁盤。目前大多數的存儲引擎都是這樣實現的。 如果數據的修改已經記錄到事務日誌並持久化，但數據本身還沒有寫回磁盤，此時系統崩潰，存儲引擎在重啓時能夠自動恢復這部分修改的數據。具有的恢復方式則視存儲引擎而定。
1）查看事務日誌的定義
mysql> show global variables like 'innodb_lo%';在上述指令輸出的部分內容解釋如下：
| innodb_flush_log_at_trx_commit | 1 #在事務提交時innodb是否同步日誌從緩衝區到文件
中，當這個值爲1（默認值）之時，在每個事務提交時，日誌緩衝被寫到日誌文件，對日誌文件做到磁盤操作的刷新，性能會很差造成大量的磁盤I/O但這種方式最安全；如果設爲2,每次提交事務都會寫日誌，但並不會執行刷的操作。每秒定時會刷到日誌文件。要注意的是，並不能保證100%每秒一定都會刷到磁盤，這要取決於進程的調度。每次事務提交的時候將數據寫入事務日誌，而這裏的寫入僅是調用了文件系統的寫入操作，而文件系統是有緩存的，所以這個寫入並不能保證數據已經寫入到物理磁盤。設置爲0，日誌緩衝每秒一次地被寫到日誌文件，並且對日誌文件做到磁盤操作的刷新，但是在一個事務提交不做任何操作。
注：刷寫的概念
刷寫其實是兩個操作，刷（flush）和寫（write），區分這兩個概念是很重要的。在大多數的操作系統中，把Innodb的log buffer（內存）寫入日誌（調用系統調用write），只是簡單的把數據移到操作系統緩存中，操作系統緩存同樣指的是內存。並沒有實際的持久化數據。
所以，通常設爲0和2的時候，在崩潰或斷電的時候會丟失最後一秒的數據，因爲這個時候數據只是存在於操作系統緩存。之所以說“通常”，可能會有丟失不只1秒的數據的情況，比如說執行flush操作的時候阻塞了。
總結
設爲1當然是最安全的，但性能頁是最差的（相對其他兩個參數而言，但不是不能接受）。如果對數據一致性和完整性要求不高，完全可以設爲2,如果只最求性能，例如高併發寫的日誌服務器，設爲0來獲得更高性能。
+--------------------------------+----------+
| Variable_name | Value |
+--------------------------------+----------+
| innodb_lock_wait_timeout | 50 |
| innodb_locks_unsafe_for_binlog | OFF |
| innodb_log_buffer_size | 16777216 |
| innodb_log_checksums | ON |
| innodb_log_compressed_pages | ON |
| innodb_log_file_size | 50331648 | #日誌文件大小
| innodb_log_files_in_group | 2 | # DB中設置幾組事務日誌，默認是2
| innodb_log_group_home_dir | ./ | #定義innodb事務日誌組的位置,此位置設置默認爲MySQL的datadir
| innodb_log_write_ahead_size | 8192 |
+--------------------------------+----------+每個事務日誌都是大小爲50兆的文件（不同版本的mysql有差異）： 在mysql中默認以ib_logfile0,ib_logfile1名稱存在。
4、慢查詢日誌（slow query log）
顧名思義，慢查詢日誌中記錄的是執行時間較長的query，也就是我們常說的slow query。 慢查詢日誌採用的是簡單的文本格式，可以通過各種文本編輯器查看其中的內容。其中 記錄了語句執行的時刻，執行所消耗的時間，執行用戶，連接主機等相關信息。 慢查詢日誌的作用： 慢查詢日誌是用來記錄執行時間超過指定時間的查詢語句。通過慢查詢日誌，可以查找出哪些查詢語句的執行效率很低，以便進行優化。一般建議開啓，它對服務器性能的影響微乎其微，但是可以記錄mysql服務器上執行了很長時間的查詢語句。可以幫助我們定位性能問題的。MySQL 還提供了專門用來分析滿查詢日誌的工具程序mysqldumpslow，用來幫助數據庫管理人員解決可能存在的性能問題。
1）查看慢查詢日誌的定義
注：在不同的mysql版本中，開啓慢查詢日誌參數不太一樣，不過都可以通過 show variables like "%slow%" 和show variables like "%long%"查看出來。
mysql> show global variables like '%slow_query_log%'; #查詢慢查詢日誌是否開啓
+---------------------+--------------------------------------+
| Variable_name | Value |
+---------------------+--------------------------------------+
| slow_query_log | OFF |
| slow_query_log_file | /usr/local/mysql/data/mysql-slow.log |
+---------------------+--------------------------------------+
2 rows in set (0.00 sec)
#上面指定的使慢查詢日誌的記錄的位置
mysql> show global variables like '%long%'; # 查看如何定義語句爲慢查詢語句
+----------------------------------------------------------+-----------+
| Variable_name | Value |
+----------------------------------------------------------+-----------+
| long_query_time | 10.000000 |
| performance_schema_events_stages_history_long_size | 10000 |
| performance_schema_events_statements_history_long_size | 10000 |
| performance_schema_events_transactions_history_long_size | 10000 |
| performance_schema_events_waits_history_long_size | 10000 |
+----------------------------------------------------------+-----------+
5 rows in set (0.00 sec)
#在上面的結果中，long_query_time的值就是慢查詢超時時間，
默認爲10s，只要執行耗時超過10s的語句就被定義爲慢查詢語句2）啓動和設置慢查詢日誌
啓動慢查詢日誌記錄：
方法1：通過配置文件my.cnf開啓慢查詢日誌：
[root@mysql data]# vim /etc/my.cnf
slow_query_log=1 # 1表示開啓慢查詢
slow_query_log_file=/usr/local/mysql/data/mysql-slow.log #指定慢查詢日誌位置
long_query_time=0.0001 #指定超時時間，也就是超過這個時間就會被記錄到慢查詢日誌
slow_launch_time=1 #如果建立線程花費了比這個值更長的時間，slow_launch_threads計數器將增加
[root@mysql ~]# systemctl restart mysqld #重啓服務使配置生效再次登錄數據庫查看相關信息，會發現更改已經生效，如下：
方法2：通過登錄MySQL服務器直接定義，方式如下：
mysql> set global slow_query_log=1;
mysql> set global long_query_time=0.0001;在上面的定義中，global表示全局生效，還有一個選項是session，表示僅在當前會話生效，其區別是，session在退出當前會話後就會被重置，global則是在重啓MySQL服務後纔會被重置，而方法1中寫入配置文件中的方法，則是真正的永久生效。
注意：如果主配置文件中定義了long_query_time的值，並且MySQL命令行中使用set指令又定義了long_query_time的值，則配置文件中定義的值優先生效。
修改後的相關設置如下：
在終端命令行使用mysqldumpslow命令工具查看慢查詢日誌：
若想要查詢到慢查詢日誌，必須保證兩點，首先是將慢查詢的超時時間設置的短一些，比如我在上面設置爲了0.0001，只要查詢的時間超過了這個值，則被定義爲慢查詢。（爲了驗證效果，在生產環境中還是要結合實際情況）。第二呢，就是在開啓慢查詢後還需要執行幾條查詢語句，以便產生日誌記錄信息（自己隨便查詢兩句吧）。
mysqldumpslow指令的部分選項解釋：
使用選項查看慢查詢日誌：
[root@mysql data]# mysqldumpslow -t 2 -a -s c mysql-slow.log
#以次數來排序，查詢前兩條，並且顯示語句的所有內容5、數據文件
在MySQL 中每一個數據庫都會在定義好（或者默認）的數據目錄下存在一個以數據庫名字命名的文件夾，用來存放該數據庫中各種表數據文件。不同的MySQL 存儲引擎有各自不同的數據文件。如MyISAM 用“.MYD”作爲擴展名，Innodb 用“.ibd”，Archive 用“.arc”，CSV 用“.csv”，等等。
“.frm”文件 與表相關的元數據（meta）信息都存放在“.frm”文件中，包括表結構的定義信息等。不論是什麼存儲引擎（MySQL常用的兩個存儲引擎是MyISAM和InnoDB），每一個表都會有一個以表名命名的“.frm”文件。所有的“.frm”文件都存放在所屬數據庫的文件夾下面。
MyISAM數據庫表文件
.MYD文件：表數據文件；.MYI文件：索引文件
“.MYD”文件 “.MYD”文件是MyISAM存儲引擎專用，存放MyISAM 表的數據。每一個MyISAM 表都會有一個“.MYD”文件與之對應，同樣存放於所屬數據庫的文件夾下，和“.frm”文件在一起
“.MYI”文件 “.MYI”文件也是專屬於MyISAM 存儲引擎的，主要存放MyISAM 表的索引相關信息。對於MyISAM 存儲來說，可以被cache 的內容主要就是來源於“.MYI”文件中。每
一個MyISAM 表對應一個“.MYI”文件，存放於位置和“.frm”以及“.MYD”一樣。
Innodb數據庫表文件
InnoDB採用表空間（tablespace）來管理數據，存儲表數據和索引。
- .ibd文件：單表表空間文件，每個表使用一個表空間文件（file per table），存放用戶數據庫表數據和索引。
- InnoDB共享表空間（即InnoDB文件集，ibfile set）：ibdata1、ibdata2等，存儲InnoDB系統信息和用戶數據庫表數據和索引，所有表共用。
- “.ibd”文件和ibdata 文件 這兩種文件都是存放Innodb 數據的文件，之所以有兩種文件來存放Innodb 的數據（包括索引），是因爲Innodb 的數據存儲方式能夠通過配置來決定是使用共享表空間存放存儲數據，還是獨享表空間存放存儲數據。獨享表空間存儲方式使用“.ibd”文件來存放數據，且每個表一個“.ibd”文件，文件存放在和MyISAM數據相同的位置。
- 如果選用共享存儲表空間來存放數據，則會使用ibdata 文件來存放，所有表共同使用一個
- （或者多個，可自行配置）ibdata 文件。 ibdata 文件可以通過innodb_data_home_dir 和innodb_data_file_path兩個參數共同配置組成， innodb_data_home_dir 配置數據存放的總目錄， 而innodb_data_file_path 配置每一個文件的名稱。 innodb_data_file_path 中可以一次配置多個ibdata 文件。文件可以是指定大小，也可以是自動擴展的，但是Innodb 限制了僅僅只有最後一個ibdata 文件能夠配置成自動擴展類型。當我們需要添加新的ibdata 文件的時候，只能添加在innodb_data_file_path配置的最後，而且必須重啓MySQL 才能完成ibdata 的添加工作。不過如果我們使用獨享表空間存儲方式的話，就不會有這樣的問題。
總結
共享表空間以及獨佔表空間都是針對數據的存儲方式而言的。 共享表空間: 某一個數據庫的所有的表數據，索引文件全部放在一個文件中。 獨佔表空間: 每一個表都將會生成以獨立的文件方式來進行存儲，每一個表都有一個.frm表描述文件，還有一個.ibd文件。其中這個文件包括了單獨一個表的數據內容以及索引內容。
兩者之間的優缺點
共享表空間：
優點： 可以放表空間分成多個文件存放到各個磁盤上。數據和文件放在一起方便管理。
缺點： 所有的數據和索引存放到一個文件中，多個表及索引在表空間中混合存儲，這樣對於一個表做了大量刪除操作後表空間中將會有大量的空隙，特別是對於統計分析，日值系統這類應用最不適合用共享表空間。
獨立表空間：
優點：
- 每個表都有自已獨立的表空間。
- 每個表的數據和索引都會存在自已的表空間中。
- 可以實現單表在不同的數據庫中移動。
- 空間可以回收
- a) Drop table操作自動回收表空間，如果對於統計分析或是日值表，刪除大量數據後可以通過:alter table TableName engine=innodb;回縮不用的空間。
- b)對於使用獨立表空間的表，不管怎麼刪除，表空間的碎片不會太嚴重的影響性能，而且還有機會處理。
- 缺點： 單表增加過大，如超過100個G。 相比較之下，使用獨佔表空間的效率以及性能會更高一點。
1）查看當前數據庫的表空間管理類型
mysql> show variables like '%innodb_file_per%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_file_per_table | ON |
+-----------------------+-------+
1 row in set (0.00 sec)ON代表獨立表空間管理，OFF代表共享表空間管理；（查看單表的表空間管理方式，需要查看每個表是否有單獨的數據文件）。
2）修改爲Innodb共享表空間
[root@mysql data]# vim /etc/my.cnf
innodb_file_per_table=0 #0爲使用共享表空間，1爲獨佔表空間
innodb_data_file_path=ibdata1:100M:autoextend #設置一個可自動擴展大小，尺寸爲100M的數據文件
innodb_data_home_dir=/usr/local/mysql/data #定義共享表空間默認存放路徑
[root@mysql ~]# systemctl restart mysqld #啓動報錯了
Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.查看日誌如下：
注：不同版本的mysql報錯略有不同，注意看錯誤日誌的內容。大概意思就是設置的pages頁爲6400，超過了它的最大值4864，那麼算一下，設置的初始大小100M，pages大小就是6400，則表示1M=64pages，它的最大值是4864，也就是說，我們設置初始大小最大可以是4864/64=76M。
再次修改配置文件如下：
[root@mysql ~]# vim /etc/my.cnf #再次修改主配置文件
innodb_data_file_path=ibdata1:76M:autoextend
#修改初始大小爲76M
[root@mysql ~]# systemctl restart mysqld #再次重啓MySQL服務
#同樣，如果還是啓動失敗，則再次查看錯誤日誌，是否pages頁大小設置的還是不合理3）查看修改後數據庫的表空間管理類型