MySQL日誌

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();

一、錯誤日誌
在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值得含義以下:

錯誤日誌的存放路徑在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 文件誕生

二、二進制日誌
二進制日誌主要記錄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以前的日誌文件

三、事務日誌
事務日誌（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名稱存在。
四、慢查詢日誌（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 
#以次數來排序，查詢前兩條，而且顯示語句的全部內容

五、數據文件
在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」同樣。

Inodb數據庫表文件

InnoDB採用表空間（tablespace）來管理數據，存儲表數據和索引。

* .ibd文件：單表表空間文件，每一個表使用一個表空間文件（file per table），存放用戶數據庫表數據和索引。
* InnoDB共享表空間（即InnoDB文件集，ibfile set）：ibdata一、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）查看修改後數據庫的表空間管理類型