mysql中日志主要分為以下幾種：錯誤日志、慢查詢日志、二進制日志和事務日志。

1. 錯誤日志

記錄mysql啟動時發生的錯誤信息，沒什么好說的，因為工作中不常用。

2. 慢查詢日志

這是mysql維護的一個日志文件，它用來自動記錄執行時間超過某個閾值的SQL語句，通過查看這個日志，我們一般可以發現運行的慢SQL，

這個閾值通過long_query_time 變量可以控制，默認是10,我們可以使用如下命令查看和修改

show variables like 'long_query_time' ;

set global long_query_time = 1;

一般來說，并發量高的業務的SQL都需要走索引，正常走索引的查詢SQL會控制在幾十ms以內，如果表數據量很小的話，幾ms就夠了，所以long_query_time設置的小一點比較好，例如200ms。

當然，mysql記錄這個日志肯定是需要耗費一定的性能的，所以它設置了一個變量slow_query_log來控制是否記錄慢查詢日志(默認是關閉的)，個人感覺不會造成多大的壓力，如果你的工程沒有在業務層做sql監控的話，這個還是很有必要的。

3. binlog日志(歸檔日志)

這個大家應該聽的比較多，數據備份恢復、主從同步等之類的都是依賴這個實現的，有些還要監聽binlog做一些數據同步，例如同步到es中等等。

那么binlog到底是什么東西呢？

binlog又叫二進制日志文件，它會將mysql中所有修改數據庫數據的請求以二進制的形式記錄到日志文件中，所以像一些select就不會存儲在這里。binlog是Server層的日志，也就是所有存儲引擎(innodb、myisam等)都會有binlog日志。

一般來說,binlog日志是不會開啟的，開啟之后性能會有 1% 的下降。想要開啟這個日志的話，我們可以在my.ini中添加如下配置

log-bin = [ on | filename ] ; 【filename表示生成的日志文件名字】

例如：log-bin = mysql-bin

binlog 是以二進制形式存儲的邏輯日志，每次有需要記錄的日志，就會追加在文件的末尾，一般，binlog有兩種模式：

statement 格式:記錄的是執行的sql

row 格式：記錄的是sql影響的行的內容，記錄兩條，更新前和更新后的。

4.事務日志

事務日志是innodb獨有的日志文件：包括redo log 和 undo log。它是用來做崩潰恢復和事務回滾的。

redo Log : 是物理日志，記錄的是某個數據頁的物理修改，而不是某一行或某幾行修改成怎樣怎樣，它用來恢復提交后的物理數據頁(恢復數據頁，且只能恢復到最后一次提交的位置)。

undo Log : 是邏輯日志，根據每行記錄進行記錄，用來回滾到某個版本，它和redo log正相反，記錄某數據被修改前的值，可以用來在事務失敗時進行rollback。

重點可以說一下redo log,它的空間是固定大小的，在邏輯上是一個閉環，從頭開始寫，寫到末尾之后又從頭開始寫，所以，redo log 維護了兩個指針位置：

write point :當前可寫的位置，不斷寫不斷往后移動

check point當前要擦除的位置，擦了之后往后移動。

從這里我們就可以看出redo log 有兩個特性：順序寫和批量提交。

說了這么多，我們可以來用一個簡單的例子來大致看一下這些日志記錄的 順序與區別：(假設binlog 是statement模式的)。

例如我們要執行：

update tableA set a = 1 where id = 1000000

語句經過優化器生成執行計劃，然后發現Id是主鍵索引，可以選擇Id索引。

執行器拿到這個sql后，調用存儲引擎接口，去索引樹上找id = 1 的數據，如果正好在內存中有，則直接返回數據；如果沒有，則去磁盤中把對應的數據頁讀到內存中返回(可能不止一次IO操作)；

執行器拿到數據之后，將 a 賦值為1，然后再調用引擎接口寫入這個修改后數據。

引擎收到更新請求，生成一個全局唯一的事務ID(XID)，然后將這個記錄更新到緩存，然后記錄redo log (包含XID)和 undo log, 此時redo log 狀態變為 prepare 狀態，并返回成功給執行器。

執行器收到成功之后，記錄這個操作的binlog 日志(其中包含XID)

執行器調用引擎的commit接口，將redo log 改成commit狀態，結束。

待續......

總結

以上是生活随笔為你收集整理的mysql业务 日志_mysql笔记之日志篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。