MySQL中有六種日志文件
1、重做日志（redo log）、回滾日志（undo log）、二進(jìn)制日志（binlog）、錯(cuò)誤日志（errorlog）、慢查詢?nèi)罩荆╯low query log）、一般查詢?nèi)罩荆╣eneral log），中繼日志（relay log）。?
2、其中重做日志和回滾日志與事務(wù)操作息息相關(guān)，二進(jìn)制日志也與事務(wù)操作有一定的關(guān)系，這三種日志，對(duì)理解MySQL中的事務(wù)操作有著重要的意義。
MySQL數(shù)據(jù)目錄
#?????cat /etc/my.cnf|grep datadir
進(jìn)入MySQL
#????mysql -uroot -proot???
一般日志（general log）
查看日志文件
?>????show variables like 'general_log_file';????
設(shè)置開啟日志
>???? set global general_log=on;?
查看動(dòng)態(tài)日志
#????tail -f /var/lib/mysql/localhost.log
慢日志查詢（slow query log）
修改 mysql 的配置文件 my.cnf
#????vi /etc/my.cnf??
在 [mysqld] 中添加內(nèi)容
slow_query_log=TRUE ?? ??? ??? ??? ??? ??? ??? ??? ?? ?? ?? ???? ?# 開啟慢日志?
slow_query_log_file=/var/lib/mysql-files/mysql-slow-query.log? ? ? # 日志存放位置?
long_query_time=5 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??? ? ? # 超時(shí)時(shí)間1秒（超過1秒就會(huì)被記錄下來）?
重啟MySQL
#????service mysqld {start | restart | stop | status}
登錄 MySQL 客戶端，查看 slow_query_log 變量
>????show variables like '%quer%';
###### 如果設(shè)置失敗或不生效執(zhí)行一下語句
###### MYSQL導(dǎo)入數(shù)據(jù)出現(xiàn)The MySQL server is running with the --secure-file-priv option so it cannot execute this statement
###### 方法一：
###### 這個(gè)原因其實(shí)很簡單，是因?yàn)樵诎惭bMySQL的時(shí)候限制了導(dǎo)入與導(dǎo)出的目錄權(quán)限
###### 只能在規(guī)定的目錄下才能導(dǎo)入
###### 我們需要通過下面命令查看 secure-file-priv 當(dāng)前的值是什么
查看MySQL 導(dǎo)入與導(dǎo)出的目錄權(quán)限（慢日志生成目錄需要知道到此目錄）
>? ? show variables like '%secure%';??????
執(zhí)行SQL語句數(shù)據(jù)導(dǎo)出到指定文件中（文件生成目錄需要知道到此目錄）
>????select * from user into outfile '/var/lib/mysql-files/user.log';???
重做日志（redo log）
作用
確保事務(wù)的持久性，防止在發(fā)生故障的時(shí)間點(diǎn)，尚有臟頁未寫入磁盤，在重啟mysql服務(wù)的時(shí)候，根據(jù)redo log進(jìn)行重做，從而達(dá)到事務(wù)的持久性這一特性。
內(nèi)容
物理格式的日志，記錄的是物理數(shù)據(jù)頁面的修改的信息，其redo log是順序?qū)懭雛edo log file的物理文件中去的。
什么時(shí)候產(chǎn)生
事務(wù)開始之后就產(chǎn)生redo log，redo log的落盤并不是隨著事務(wù)的提交才寫入的，而是在事務(wù)的執(zhí)行過程中，便開始寫入redo log文件中。
什么時(shí)候釋放
當(dāng)對(duì)應(yīng)事務(wù)的臟頁寫入到磁盤之后，redo log的使命也就完成了，重做日志占用的空間就可以重用（被覆蓋）。
對(duì)應(yīng)的物理文件
默認(rèn)情況下，對(duì)應(yīng)的物理文件位于數(shù)據(jù)庫的data目錄下的ib_logfile1&ib_logfile2
innodb_log_group_home_dir 指定日志文件組所在的路徑，默認(rèn)./ ，表示在數(shù)據(jù)庫的數(shù)據(jù)目錄下。
innodb_log_files_in_group 指定重做日志文件組中文件的數(shù)量，默認(rèn)2
關(guān)于文件的大小和數(shù)量，由以下兩個(gè)參數(shù)配置
innodb_log_file_size 重做日志文件的大小。
innodb_mirrored_log_groups 指定了日志鏡像文件組的數(shù)量，默認(rèn)1
其他
很重要一點(diǎn)，redo log是什么時(shí)候?qū)懕P的？前面說了是在事物開始之后逐步寫盤的。
之所以說重做日志是在事務(wù)開始之后逐步寫入重做日志文件，而不一定是事務(wù)提交才寫入重做日志緩存，原因就是
重做日志有一個(gè)緩存區(qū)Innodb_log_buffer，
Innodb_log_buffer的默認(rèn)大小為8M(這里設(shè)置的16M)，
Innodb存儲(chǔ)引擎先將重做日志寫入innodb_log_buffer中。
通過以下三種方式將innodb日志緩沖區(qū)的日志刷新到磁盤
1、Master Thread 每秒一次執(zhí)行刷新Innodb_log_buffer到重做日志文件。
2、每個(gè)事務(wù)提交時(shí)會(huì)將重做日志刷新到重做日志文件。
3、當(dāng)重做日志緩存可用空間 少于一半時(shí)，重做日志緩存被刷新到重做日志文件。
由此可以看出，重做日志通過不止一種方式寫入到磁盤，尤其是對(duì)于第一種方式，Innodb_log_buffer到重做日志文件是Master Thread線程的定時(shí)任務(wù)。
因此重做日志的寫盤，并不一定是隨著事務(wù)的提交才寫入重做日志文件的，而是隨著事務(wù)的開始，逐步開始的。
另外引用《MySQL技術(shù)內(nèi)幕 Innodb 存儲(chǔ)引擎》（page37）上的原話：即使某個(gè)事務(wù)還沒有提交，Innodb存儲(chǔ)引擎仍然每秒會(huì)將重做日志緩存刷新到重做日志文件。這一點(diǎn)是必須要知道的，因?yàn)檫@可以很好地解釋再大的事務(wù)的提交（commit）的時(shí)間也是很短暫的。
回滾日志（undo log）
作用
保存了事務(wù)發(fā)生之前的數(shù)據(jù)的一個(gè)版本，可以用于回滾，同時(shí)可以提供多版本并發(fā)控制下的讀（MVCC），也即非鎖定讀。
內(nèi)容
邏輯格式的日志，在執(zhí)行undo的時(shí)候，僅僅是將數(shù)據(jù)從邏輯上恢復(fù)至事務(wù)之前的狀態(tài)，而不是從物理頁面上操作實(shí)現(xiàn)的，這一點(diǎn)是不同于redo log的。
什么時(shí)候產(chǎn)生
事務(wù)開始之前，將當(dāng)前是的版本生成undo log，undo 也會(huì)產(chǎn)生 redo 來保證undo log的可靠性。
什么時(shí)候釋放
當(dāng)事務(wù)提交之后，undo log并不能立馬被刪除，而是放入待清理的鏈表，由purge線程判斷是否由其他事務(wù)在使用undo段中表的上一個(gè)事務(wù)之前的版本信息，決定是否可以清理undo log的日志空間。
對(duì)應(yīng)的物理文件
MySQL5.6之前，undo表空間位于共享表空間的回滾段中，共享表空間的默認(rèn)的名稱是ibdata，位于數(shù)據(jù)文件目錄中。
MySQL5.6之后，undo表空間可以配置成獨(dú)立的文件，但是提前需要在配置文件中配置，完成數(shù)據(jù)庫初始化后生效且不可改變undo log文件的個(gè)數(shù)
如果初始化數(shù)據(jù)庫之前沒有進(jìn)行相關(guān)配置，那么就無法配置成獨(dú)立的表空間了。
關(guān)于MySQL5.7之后的獨(dú)立undo 表空間配置參數(shù)如下
innodb_undo_directory = /data/undospace/ –undo獨(dú)立表空間的存放目錄
innodb_undo_logs = 128 –回滾段為128KB
innodb_undo_tablespaces = 4 –指定有4個(gè)undo log文件
如果undo使用的共享表空間，這個(gè)共享表空間中又不僅僅是存儲(chǔ)了undo的信息，共享表空間的默認(rèn)為與MySQL的數(shù)據(jù)目錄下面，其屬性由參數(shù)innodb_data_file_path配置。
其他
undo是在事務(wù)開始之前保存的被修改數(shù)據(jù)的一個(gè)版本，產(chǎn)生undo日志的時(shí)候，同樣會(huì)伴隨類似于保護(hù)事務(wù)持久化機(jī)制的redolog的產(chǎn)生。
默認(rèn)情況下undo文件是保持在共享表空間的，也即ibdatafile文件中，當(dāng)數(shù)據(jù)庫中發(fā)生一些大的事務(wù)性操作的時(shí)候，要生成大量的undo信息，全部保存在共享表空間中的。
因此共享表空間可能會(huì)變的很大，默認(rèn)情況下，也就是undo 日志使用共享表空間的時(shí)候，被“撐大”的共享表空間是不會(huì)也不能自動(dòng)收縮的。
因此，mysql5.7之后的“獨(dú)立undo 表空間”的配置就顯得很有必要了。
二進(jìn)制日志（binlog）
作用
1、用于復(fù)制，在主從復(fù)制中，從庫利用主庫上的binlog進(jìn)行重播，實(shí)現(xiàn)主從同步。
2、用于數(shù)據(jù)庫的基于時(shí)間點(diǎn)的還原。
內(nèi)容
邏輯格式的日志，可以簡單認(rèn)為就是執(zhí)行過的事務(wù)中的sql語句。
但又不完全是sql語句這么簡單，而是包括了執(zhí)行的sql語句（增刪改）反向的信息，也就意味著delete對(duì)應(yīng)著delete本身和其反向的insert；update對(duì)應(yīng)著update執(zhí)行前后的版本的信息；insert對(duì)應(yīng)著delete和insert本身的信息。
在使用mysqlbinlog解析binlog之后一些都會(huì)真相大白。
因此可以基于binlog做到類似于oracle的閃回功能，其實(shí)都是依賴于binlog中的日志記錄。
什么時(shí)候產(chǎn)生
事務(wù)提交的時(shí)候，一次性將事務(wù)中的sql語句（一個(gè)事物可能對(duì)應(yīng)多個(gè)sql語句）按照一定的格式記錄到binlog中。
這里與redo log很明顯的差異就是redo log并不一定是在事務(wù)提交的時(shí)候刷新到磁盤，redo log是在事務(wù)開始之后就開始逐步寫入磁盤。
因此對(duì)于事務(wù)的提交，即便是較大的事務(wù)，提交（commit）都是很快的，但是在開啟了bin_log的情況下，對(duì)于較大事務(wù)的提交，可能會(huì)變得比較慢一些。
這是因?yàn)閎inlog是在事務(wù)提交的時(shí)候一次性寫入的造成的，這些可以通過測試驗(yàn)證。
什么時(shí)候釋放
binlog的默認(rèn)是保持時(shí)間由參數(shù)expire_logs_days配置，也就是說對(duì)于非活動(dòng)的日志文件，在生成時(shí)間超過expire_logs_days配置的天數(shù)之后，會(huì)被自動(dòng)刪除。
對(duì)應(yīng)的物理文件
配置文件的路徑為log_bin_basename，binlog日志文件按照指定大小，當(dāng)日志文件達(dá)到指定的最大的大小之后，進(jìn)行滾動(dòng)更新，生成新的日志文件。
對(duì)于每個(gè)binlog日志文件，通過一個(gè)統(tǒng)一的index文件來組織。
其他
二進(jìn)制日志的作用之一是還原數(shù)據(jù)庫的，這與redo log很類似，很多人混淆過，但是兩者有本質(zhì)的不同
1、作用不同：redo log是保證事務(wù)的持久性的，是事務(wù)層面的，binlog作為還原的功能，是數(shù)據(jù)庫層面的（當(dāng)然也可以精確到事務(wù)層面的），雖然都有還原的意思，但是其保護(hù)數(shù)據(jù)的層次是不一樣的。
2、內(nèi)容不同：redo log是物理日志，是數(shù)據(jù)頁面的修改之后的物理記錄，binlog是邏輯日志，可以簡單認(rèn)為記錄的就是sql語句
3、另外，兩者日志產(chǎn)生的時(shí)間，可以釋放的時(shí)間，在可釋放的情況下清理機(jī)制，都是完全不同的。
4、恢復(fù)數(shù)據(jù)時(shí)候的效率，基于物理日志的redo log恢復(fù)數(shù)據(jù)的效率要高于語句邏輯日志的binlog
關(guān)于事務(wù)提交時(shí)，redo log和binlog的寫入順序，為了保證主從復(fù)制時(shí)候的主從一致（當(dāng)然也包括使用binlog進(jìn)行基于時(shí)間點(diǎn)還原的情況），是要嚴(yán)格一致的，MySQL通過兩階段提交過程來完成事務(wù)的一致性的，也即redo log和binlog的一致性的，理論上是先寫redo log，再寫binlog，兩個(gè)日志都提交成功（刷入磁盤），事務(wù)才算真正的完成。
配置
查看binlog日志的狀態(tài)
?>????show variables like 'log_bin%';???
開啟binlog日志
#????vi /etc/my.cnf?
### 添加以下參數(shù)?
server_id=1918? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?### server-id表示單個(gè)結(jié)點(diǎn)的id，這里由于只有一個(gè)結(jié)點(diǎn)，所以可以把id隨機(jī)指定為一個(gè)數(shù)，這里將id設(shè)置成1。若集群中有多個(gè)結(jié)點(diǎn)，則id不能相同
log_bin = /var/lib/mysql/mysql-binlog? ? ? ### 日志文件的名字為mysql-bin，以及其存儲(chǔ)路徑（默認(rèn)此路徑）
binlog_format = ROW? ? ? ? ? ? ? ? ? ? ? ? ? ? ?### 基于SQL語句的復(fù)制(statement-based replication, SBR)，基于行的復(fù)制(row-based replication, RBR)，混合模式復(fù)制(mixed-based replication, MBR)。對(duì)應(yīng)的，binlog的格式也有三種：STATEMENT，ROW，MIXED。
重啟MySQL
#????service mysqld restart
查看/var/lib/mysql目錄下的內(nèi)容
#????ll /var/lib/mysql
參考：https://blog.csdn.net/wanbin6470398/article/details/81941586
redo log日志與binlog日志的區(qū)別
1、redo log是在InnoDB存儲(chǔ)引擎層產(chǎn)生，而binlog是MySQL數(shù)據(jù)庫的上層產(chǎn)生的，并且二進(jìn)制日志不僅僅針對(duì)INNODB存儲(chǔ)引擎，MySQL數(shù)據(jù)庫中的任何存儲(chǔ)引擎對(duì)于數(shù)據(jù)庫的更改都會(huì)產(chǎn)生二進(jìn)制日志。
2、兩種日志記錄的內(nèi)容形式不同。MySQL的binlog是邏輯日志，其記錄是對(duì)應(yīng)的SQL語句。而innodb存儲(chǔ)引擎層面的重做日志是物理日志。
3、兩種日志與記錄寫入磁盤的時(shí)間點(diǎn)不同，二進(jìn)制日志只在事務(wù)提交完成后進(jìn)行一次寫入。而innodb存儲(chǔ)引擎的重做日志在事務(wù)進(jìn)行中不斷地被寫入，并日志不是隨事務(wù)提交的順序進(jìn)行寫入的。二進(jìn)制日志僅在事務(wù)提交時(shí)記錄，并且對(duì)于每一個(gè)事務(wù)，僅在事務(wù)提交時(shí)記錄，并且對(duì)于每一個(gè)事務(wù)，僅包含對(duì)應(yīng)事務(wù)的一個(gè)日志。而對(duì)于innodb存儲(chǔ)引擎的重做日志，由于其記錄是物理操作日志，因此每個(gè)事務(wù)對(duì)應(yīng)多個(gè)日志條目，并且事務(wù)的重做日志寫入是并發(fā)的，并非在事務(wù)提交時(shí)寫入，其在文件中記錄的順序并非是事務(wù)開始的順序。
4、binlog不是循環(huán)使用，在寫滿或者重啟之后，會(huì)生成新的binlog文件，redo log是循環(huán)使用。
5、binlog可以作為恢復(fù)數(shù)據(jù)使用，主從復(fù)制搭建，redo log作為異常宕機(jī)或者介質(zhì)故障后的數(shù)據(jù)恢復(fù)使用。
