資料庫日誌：
首先，在mysql中預設只開啟了錯誤日誌
mysql中的日誌檔案：
這裡先談一下重做日誌以及回滾日誌以及二進位制日誌之間得關係，他們都與事務操作相關。
重做日誌：
作用：
確保事務的永續性。防止在發生故障的時間點，尚有髒頁未寫入磁碟，在重啟mysql服務的時候，根據redo log進行重做，從而達到事務的永續性這一特性。（髒頁：linux核心中的概念，快取記憶體，linux是以頁作為快取記憶體的單位，當程序修改了快取記憶體裡的資料時，該頁就被核心標記為臟頁，核心將會在合適的時間把髒頁的資料寫到磁碟中去，以保持快取記憶體中的資料和磁碟中的資料是一致的。）
內容：
物理格式的日誌，記錄的是物理資料頁面的修改的資訊，其redo log是順序寫入redo log file的物理檔案中去的。
什麼時候產生：
事務開始之後就產生redo log，redo log的落盤並不是隨著事務的提交才寫入的，而是在事務的執行過程中，便開始寫入redo log檔案中。
之所以說重做日誌是在事務開始之後逐步寫入重做日誌檔案，而不一定是事務提交才寫入重做日誌快取，原因就是，重做日誌有乙個快取區innodb_log_buffer，innodb_log_buffer的預設大小為8m,innodb儲存引擎先將重做日誌寫入innodb_log_buffer中。然後通過其他方式將innodb日誌緩衝區的日誌重新整理到磁碟。
什麼時候釋放：
當對應事務的髒頁寫入到磁碟之後，redo log的使命也就完成了，重做日誌占用的空間就可以重用（被覆蓋）。
對應的物理檔案：
預設情況下，對應的物理檔案位於資料庫的data目錄下的ib_logfile1&ib_logfile2（預設檔案組的數量是2）
回滾日誌：
作用：
儲存了事務發生之前的資料的乙個版本，可以用於回滾，同時可以提供多版本併發控制下的讀（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檔案的個數
如果初始化資料庫之前沒有進行相關配置，那麼就無法配置成獨立的表空間了。
二進位制日誌：
作用：
用於複製，在主從複製中，從庫利用主庫上的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檔案來組織。
錯誤日誌：
存放伺服器啟動和關閉過程中的資訊，伺服器執行過程中的錯誤資訊，事件排程器執行乙個事件時產生的資訊、在從伺服器上啟動從伺服器程序時產生的資訊。
查詢日誌：
這是最不應該記錄的日誌。因為乙個非常繁忙的資料庫伺服器，其查詢會有很多，每一次都記錄日誌會導致系統效能下降。而且還會有額外的空間開銷。mysql預設沒有開啟這個日誌。注意不僅僅是select。
慢查詢日誌：
查詢執行時長超過指定時長的查詢，即為慢查詢。這裡的慢不一定是語句自身執行慢，如果乙個操作鎖定了某張表，尤其是獨佔鎖鎖定了這張表，那麼其他人對於這張表的查詢就阻塞掉了。但不管怎麼講，慢查詢日誌是我們通常拿來定位系統上查詢操作執行速度過慢時常用到的乙個評估工具。所以在生產環境中有時是很有必要啟用慢查日誌的。
中繼日誌：
在從伺服器上的日誌。就是說主從複製的時候，主伺服器任何能夠產生資料修改的操作，在寫入資料檔案的同時，還會把這個語句(也可能是行)記錄到二進位制日誌檔案中乙份。從伺服器就是使用乙個使用者帳號不斷的去連線主伺服器，並嘗試去讀取主伺服器上二進位制日誌中的每乙個條目，從伺服器將這些挨個的讀到從伺服器上，在執行之前，先要將這些讀到的儲存在本地的日誌檔案中，而後從本地日誌檔案中讀一條執行一條。這個日誌檔案就叫做中繼日誌。
清空資料庫日誌
最好備份日誌，以後可通過日誌恢復資料。以下為日誌處理方法 一般不建議做第4,6兩步 第4步不安全,有可能損壞資料庫或丟失資料 第6步如果日誌達到上限,則以後的資料庫處理會失敗,在清理日誌後才能恢復.下面的所有庫名都指你要處理的資料庫的庫名 1.清空日誌 dump transaction 庫名 wit...
壓縮資料庫日誌
經常在csdn上看到發帖說,壓縮日誌檔案處理不當,導致資料庫損壞,甚至不能恢復資料,於是就寫了乙個通用的資料庫日誌檔案壓縮的儲存過程來解決此問題 壓縮資料庫的通用儲存過程 壓縮日誌及資料庫檔案大小 因為要對資料庫進行分離處理 所以儲存過程不能建立在被壓縮的資料庫中 鄒建 2004.03 引用請保留此...
壓縮資料庫日誌
經常在csdn上看到發帖說,壓縮日誌檔案處理不當,導致資料庫損壞,甚至不能恢復資料,於是就寫了乙個通用的資料庫日誌檔案壓縮的儲存過程來解決此問題 壓縮資料庫的通用儲存過程 壓縮日誌及資料庫檔案大小 因為要對資料庫進行分離處理 所以儲存過程不能建立在被壓縮的資料庫中 鄒建 2004.03 引用請保留此...