本文目錄一覽：
mysql中哪種日誌不能直接cat或more
前言
MySQL中有以下日誌文件，分別是：
1：重做日誌（redo log）
2：回滾日誌（undo log）
3：二進位日誌（binlog）
4：錯誤日誌（errorlog）
5：慢查詢日誌（slow query log）
6：一般查詢日誌（general log）
7：中繼日誌（relay log）。
其中重做日誌和回滾日誌與事務操作息息相關，二進位日誌也與事務操作有一定的關係，這三種日誌，對理解MySQL中的事務操作有著重要的意義。
一、重做日誌（redo log）
作用：
確保事務的持久性。redo日誌記錄事務執行後的狀態，用來恢復未寫入data file的已成功事務更新的數據。防止在發生故障的時間點，尚有臟頁未寫入磁碟，在重啟mysql服務的時候，根據redo log進行重做，從而達到事務的持久性這一特性。
內容：
物理格式的日誌，記錄的是物理數據頁面的修改的信息，其redo log是順序寫入redo log file的物理文件中去的。
什麼時候產生：
事務開始之後就產生redo log，redo log的落盤並不是隨著事務的提交才寫入的，而是在事務的執行過程中，便開始寫入redo log文件中。
什麼時候釋放：
當對應事務的臟頁寫入到磁碟之後，redo log的使命也就完成了，重做日誌佔用的空間就可以重用（被覆蓋）。
對應的物理文件：
默認情況下，對應的物理文件位於資料庫的data目錄下的ib_logfile1ib_logfile2
innodb_log_group_home_dir 指定日誌文件組所在的路徑，默認./ ，表示在資料庫的數據目錄下。
innodb_log_files_in_group 指定重做日誌文件組中文件的數量，默認2
關於文件的大小和數量，由以下兩個參數配置：
innodb_log_file_size 重做日誌文件的大小。
innodb_mirrored_log_groups 指定了日誌鏡像文件組的數量，默認1
其他：
很重要一點，redo log是什麼時候寫盤的？前面說了是在事物開始之後逐步寫盤的。
之所以說重做日誌是在事務開始之後逐步寫入重做日誌文件，而不一定是事務提交才寫入重做日誌緩存，原因就是，重做日誌有一個緩存區Innodb_log_buffer，Innodb_log_buffer的默認大小為8M(這裡設置的16M),Innodb存儲引擎先將重做日誌寫入innodb_log_buffer中。
然後會通過以下三種方式將innodb日誌緩衝區的日誌刷新到磁碟
Master Thread 每秒一次執行刷新Innodb_log_buffer到重做日誌文件。
每個事務提交時會將重做日誌刷新到重做日誌文件。
當重做日誌緩存可用空間 少於一半時，重做日誌緩存被刷新到重做日誌文件
由此可以看出，重做日誌通過不止一種方式寫入到磁碟，尤其是對於第一種方式，Innodb_log_buffer到重做日誌文件是Master Thread線程的定時任務。
因此重做日誌的寫盤，並不一定是隨著事務的提交才寫入重做日誌文件的，而是隨著事務的開始，逐步開始的。
另外引用《MySQL技術內幕 Innodb 存儲引擎》（page37）上的原話：
即使某個事務還沒有提交，Innodb存儲引擎仍然每秒會將重做日誌緩存刷新到重做日誌文件。
這一點是必須要知道的，因為這可以很好地解釋再大的事務的提交（commit）的時間也是很短暫的。
二、回滾日誌（undo log）
作用：
保證數據的原子性，保存了事務發生之前的數據的一個版本，可以用於回滾，同時可以提供多版本並發控制下的讀（MVCC），也即非鎖定讀
內容：
邏輯格式的日誌，在執行undo的時候，僅僅是將數據從邏輯上恢復至事務之前的狀態，而不是從物理頁面上操作實現的，這一點是不同於redo log的。
什麼時候產生：
事務開始之前，將當前是的版本生成undo log，undo 也會產生 redo 來保證undo log的可靠性
什麼時候釋放：
當事務提交之後，undo log並不能立馬被刪除，而是放入待清理的鏈表，由purge線程判斷是否由其他事務在使用undo段中表的上一個事務之前的版本信息，決定是否可以清理undo log的日誌空間。
對應的物理文件：
MySQL5.6之前，undo表空間位於共享表空間的回滾段中，共享表空間的默認的名稱是ibdata，位於數據文件目錄中。
MySQL5.6之後，undo表空間可以配置成獨立的文件，但是提前需要在配置文件中配置，完成資料庫初始化後生效且不可改變undo log文件的個數
如果初始化資料庫之前沒有進行相關配置，那麼就無法配置成獨立的表空間了。
關於MySQL5.7之後的獨立undo 表空間配置參數如下：
innodb_undo_directory = /data/undospace/ –undo獨立表空間的存放目錄 innodb_undo_logs = 128 –回滾段為128KB innodb_undo_tablespaces = 4 –指定有4個undo log文件
如果undo使用的共享表空間，這個共享表空間中又不僅僅是存儲了undo的信息，共享表空間的默認為與MySQL的數據目錄下面，其屬性由參數innodb_data_file_path配置。
其他：
undo是在事務開始之前保存的被修改數據的一個版本，產生undo日誌的時候，同樣會伴隨類似於保護事務持久化機制的redolog的產生。
默認情況下undo文件是保持在共享表空間的，也即ibdatafile文件中，當資料庫中發生一些大的事務性操作的時候，要生成大量的undo信息，全部保存在共享表空間中的。
因此共享表空間可能會變的很大，默認情況下，也就是undo 日誌使用共享表空間的時候，被「撐大」的共享表空間是不會也不能自動收縮的。
因此，mysql5.7之後的「獨立undo 表空間」的配置就顯得很有必要了。
三、二進位日誌（binlog）：
作用：
用於複製，在主從複製中，從庫利用主庫上的binlog進行重播，實現主從同步。
用於資料庫的基於時間點的還原。
內容：
邏輯格式的日誌，可以簡單認為就是執行過的事務中的sql語句。
但又不完全是sql語句這麼簡單，而是包括了執行的sql語句（增刪改）反向的信息，也就意味著delete對應著delete本身和其反向的insert；update對應著update執行前後的版本的信息；insert對應著delete和insert本身的信息。
在使用mysqlbinlog解析binlog之後一些都會真相大白。
因此可以基於binlog做到類似於oracle的閃回功能，其實都是依賴於binlog中的日誌記錄。
什麼時候產生：
事務提交的時候，一次性將事務中的sql語句（一個事物可能對應多個sql語句）按照一定的格式記錄到binlog中。
這裡與redo log很明顯的差異就是redo log並不一定是在事務提交的時候刷新到磁碟，redo log是在事務開始之後就開始逐步寫入磁碟。
因此對於事務的提交，即便是較大的事務，提交（commit）都是很快的，但是在開啟了bin_log的情況下，對於較大事務的提交，可能會變得比較慢一些。
這是因為binlog是在事務提交的時候一次性寫入的造成的，這些可以通過測試驗證。
什麼時候釋放：
binlog的默認是保持時間由參數expire_logs_days配置，也就是說對於非活動的日誌文件，在生成時間超過expire_logs_days配置的天數之後，會被自動刪除。
對應的物理文件：
配置文件的路徑為log_bin_basename，binlog日誌文件按照指定大小，當日誌文件達到指定的最大的大小之後，進行滾動更新，生成新的日誌文件。
對於每個binlog日誌文件，通過一個統一的index文件來組織。
其他：
二進位日誌的作用之一是還原資料庫的，這與redo log很類似，很多人混淆過，但是兩者有本質的不同
作用不同：redo log是保證事務的持久性的，是事務層面的，binlog作為還原的功能，是資料庫層面的（當然也可以精確到事務層面的），雖然都有還原的意思，但是其保護數據的層次是不一樣的。
內容不同：redo log是物理日誌，是數據頁面的修改之後的物理記錄，binlog是邏輯日誌，可以簡單認為記錄的就是sql語句
另外，兩者日誌產生的時間，可以釋放的時間，在可釋放的情況下清理機制，都是完全不同的。
恢複數據時候的效率，基於物理日誌的redo log恢複數據的效率要高於語句邏輯日誌的binlog
關於事務提交時，redo log和binlog的寫入順序，為了保證主從複製時候的主從一致（當然也包括使用binlog進行基於時間點還原的情況），是要嚴格一致的，MySQL通過兩階段提交過程來完成事務的一致性的，也即redo log和binlog的一致性的，理論上是先寫redo log，再寫binlog，兩個日誌都提交成功（刷入磁碟），事務才算真正的完成。
四、錯誤日誌
錯誤日誌記錄著mysqld啟動和停止,以及伺服器在運行過程中發生的錯誤的相關信息。在默認情況下，系統記錄錯誤日誌的功能是關閉的，錯誤信息被輸出到標準錯誤輸出。
指定日誌路徑兩種方法:
編輯my.cnf 寫入 log-error=[path]
通過命令參數錯誤日誌 mysqld_safe –user=mysql –log-error=[path]
顯示錯誤日誌的命令（如下圖所示）
五、普通查詢日誌 general query log
記錄了伺服器接收到的每一個查詢或是命令，無論這些查詢或是命令是否正確甚至是否包含語法錯誤，general log 都會將其記錄下來 ，記錄的格式為 {Time ，Id ，Command，Argument }。也正因為mysql伺服器需要不斷地記錄日誌，開啟General log會產生不小的系統開銷。 因此，Mysql默認是把General log關閉的。
查看日誌的存放方式：show variables like 『log_output』;
如果設置mysql set global log_output=』table』 的話，則日誌結果會記錄到名為gengera_log的表中，這表的默認引擎都是CSV
如果設置表數據到文件set global log_output=file;
設置general log的日誌文件路徑：
set global general_log_file=』/tmp/general.log』;
開啟general log： set global general_log=on;
關閉general log： set global general_log=off;
然後在用：show global variables like 『general_log』
六、慢查詢日誌
慢日誌記錄執行時間過長和沒有使用索引的查詢語句，報錯select、update、delete以及insert語句，慢日誌只會記錄執行成功的語句。
1. 查看慢查詢時間：
show variables like 「long_query_time」;默認10s
2. 查看慢查詢配置情況：
show status like 「%slow_queries%」;
3. 查看慢查詢日誌路徑：
show variables like 「%slow%」;
4. 開啟慢日誌
查看已經開啟：
mysql binlog數據是怎麼處理的
MySQL 的 Binlog 記錄著 MySQL 資料庫的所有變更信息，了解 Binlog 的結構可以幫助我們解析Binlog，甚至對 Binlog 進行一些修改，或者說是「篡改」，例如實現類似於 Oracle 的 flashback 的功能，恢復誤刪除的記錄，把 update 的記錄再還原回去等。本文將帶您探討一下這些神奇功能的實現，您會發現比您想像地要簡單得多。本文指的 Binlog 是 ROW 模式的 Binlog，這也是 MySQL 8 里的默認模式，STATEMENT 模式因為使用中有很多限制，現在用得越來越少了。
Binlog 由事件（event）組成，請注意是事件（event）不是事務（transaction），一個事務可以包含多個事件。事件描述對資料庫的修改內容。
現在我們已經了解了 Binlog 的結構，我們可以試著修改 Binlog 里的數據。例如前面舉例的 Binlog 刪除了一條記錄，我們可以試著把這條記錄恢復，Binlog 裡面有個刪除行（DELETE_ROWS_EVENT）的事件，就是這個事件刪除了記錄，這個事件和寫行（WRITE_ROWS_EVENT）的事件的數據結構是完全一樣的，只是刪除行事件的類型是 32，寫行事件的類型是 30，我們把對應的 Binlog 位置的 32 改成 30 即可把已經刪除的記錄再插入回去。從前面的 「show binlog events」 裡面可看到這個 DELETE_ROWS_EVENT 是從位置 378 開始的，這裡的位置就是 Binlog 文件的實際位置（以位元組為單位）。從事件（event）的結構裡面可以看到 type_code 是在 event 的第 5 個位元組，我們寫個 Python 小程序把把第383（378+5=383）位元組改成 30 即可。當然您也可以用二進位編輯工具來改。
找出 Binlog 中的大事務
由於 ROW 模式的 Binlog 是每一個變更都記錄一條日誌，因此一個簡單的 SQL，在 Binlog 里可能會產生一個巨無霸的事務，例如一個不帶 where 的 update 或 delete 語句，修改了全表裡面的所有記錄，每條記錄都在 Binlog 裡面記錄一次，結果是一個巨大的事務記錄。這樣的大事務經常是產生麻煩的根源。我的一個客戶有一次向我抱怨，一個 Binlog 前滾，滾了兩天也沒有動靜，我把那個 Binlog 解析了一下，發現裡面有個事務產生了 1.4G 的記錄，修改了 66 萬條記錄！下面是一個簡單的找出 Binlog 中大事務的 Python 小程序，我們知道用 mysqlbinlog 解析的 Binlog，每個事務都是以 BEGIN 開頭，以 COMMIT 結束。我們找出 BENGIN 前面的 「# at」 的位置，檢查 COMMIT 後面的 「# at」 位置，這兩個位置相減即可計算出這個事務的大小，下面是這個 Python 程序的例子。
切割 Binlog 中的大事務
對於大的事務，MySQL 會把它分解成多個事件（注意一個是事務 TRANSACTION，另一個是事件 EVENT），事件的大小由參數 binlog-row-event-max-size 決定，這個參數默認是 8K。因此我們可以把若干個事件切割成一個單獨的略小的事務
ROW 模式下，即使我們只更新了一條記錄的其中某個欄位，也會記錄每個欄位變更前後的值，這個行為是 binlog_row_image 參數控制的，這個參數有 3 個值，默認為 FULL，也就是記錄列的所有修改，即使欄位沒有發生變更也會記錄。這樣我們就可以實現類似 Oracle 的 flashback 的功能，我個人估計 MySQL 未來的版本從可能會基於 Binlog 推出這樣的功能。
了解了 Binlog 的結構，再加上 Python 這把瑞士軍刀，我們還可以實現很多功能，例如我們可以統計哪個表被修改地最多？我們還可以把 Binlog 切割成一段一段的，然後再重組，可以靈活地進行 MySQL 資料庫的修改和遷移等工作。
怎樣查看mysql是否開啟日誌功能
1、首先確認你日誌是否啟用了mysqlshow variables like ‘log_bin’。
2、如果啟用了，即ON，那日誌文件就在mysql的安裝目錄的data目錄下。
3、怎樣知道當前的日誌mysql show master status。
4、看二進位日誌文件用mysqlbinlog，shellmysqlbinlog mail-bin.000001或者shellmysqlbinlog mail-bin.000001 | tail，Windows 下用類似的。
MySQL的日誌操作：
1、首先，登陸mysql後，執行sql語句：show variables like ‘log_bin’。
2、#錯誤日誌log-errol開啟方式：在my.ini的[mysqld]選項下：添加代碼：log-error=E:\log-error.txt。
記錄內容：主要是記錄啟動、運行或停止mysqld時出現的致命性問題，都是系統級的錯誤記錄。
3、#查詢日誌：log，開啟方式：在my.ini的[mysqld]選項下：添加代碼：log=E:/mysql_log.txt。
4、#二進位日誌：log-bin，開啟方式：在my.ini的[mysqld]選項下：添加代碼：log-bin=E:/mysql_log_bin，記錄內容：主要是記錄所有的更改數據的語句，可使用mysqlbinlog命令恢複數據。
如何在MySql中記錄SQL日誌記錄
My
SQL可以用下面方法跟蹤sql
語句，以下方法以Windows平台為例，linux雷同：
1
配置my.ini文件（在安裝目錄,linux下文件名為my.cnf
查找到[mysqld]區段，增加日誌的配置，如下示例：[mysqld]log=C:/temp/mysql.log
log_slow_queries=C:/temp/mysql_slow.log
long_query_time=1
log指示日誌文件存放目錄；
log_slow_queries指示記錄執行時間長的sql日誌目錄；
long_query_time指示多長時間算是執行時間長，單位s。
Linux下這些配置項應該已經存在，只是被注釋掉了，可以去掉注釋。但直接添加配置項也OK啦。
2
重新啟動mysql服務。注意事項：A日誌存放目錄必須提前存在，否則不能記錄日誌。這裡也局勢C:/temp目錄必須已經存在
B
日誌文件是linux格式的文本，建議用ultraEdit打開，轉換為dos格式查看（否則沒有換行，看不懂的）
C
服務在啟動狀態下不能刪除日誌文件，否則就無法記錄sql語句了。
D
不能用ultraEdit直接清除文件內容後保存，否則也記錄不下來了。需要重啟服務，如果ultraEdit保存了.bak，後記錄到此文件中。
E
可以用notepad清除文本後保存，可以繼續記錄日誌。
原創文章，作者：FJMAK，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/313730.html
微信掃一掃 
支付寶掃一掃 