默認情況下錯誤日誌大概記錄以下幾個方面的信息：

1、服務器啟動和關閉過程中的信息（未必是錯誤信息，例如，mysql如何啟動INNODB的表空間文件的、如何初始化自己的存儲引擎的等）

2、服務器運行過程中的錯誤信息

3、事件調度器運行一個事件時產生的信息

4、在從服務器上啟動服務器進程時產生的信息

註意：

1、可以根據自身需求設定不同錯誤日誌的值

1=只記錄 Errors 級別的日誌

2=記錄Errors、warnings 級別的日誌

3=記錄Errors、warnings、notes（defaults）級別的日誌

2、如何刪除舊的錯誤日誌

在mysql5.7之前：數據庫管理員可以刪除很長時間之前的錯誤日誌，以保證mysql服務器上的硬盤空間。mysql數據庫中，可以使用mysqladmin命令開啟新的錯誤日誌：

命令語法如下：mysqladmin -u root -p flush_logs 也可以登陸mysql數據庫中使用flush logs 語句來開啟新的錯誤日誌

在5.7之後：服務器將關閉此項功能。只能使用重命名原來的錯誤日誌文件，手動沖洗日誌創建一個新的

方式如下：mv mysqld.err mysqld.err.old

二進制日誌：Binary Log & Binary Log Index

二進制日誌也就是我們常說的binlog日誌，也是MySQL server 中最重要的日誌之一，主要用於記錄修改數據或有可能引起數據改變的mysql語句，並記錄了：

1、語句發生時間

2、執行時長

3、操作的數據

4、等等

所以說通過二進制日誌可以查詢mysql數據庫中進行了那些變化

一般體積上限為1G

當我們通過“log-bin=file_name”打開了記錄的功能之後，MySQL會將所有修改數據庫數據的query以二進制形式記錄到日誌文件中。當然，日誌中不僅有query語句這麽簡單，還包括每一條query所執行的時間，所消耗的資源，以及相關的事務信息，所以binlog是事務安全的。

和錯誤日誌一樣，binlog記錄功能同樣需要“bin-log=file_name”參數的顯示指定才能開啟，如果未指定file_name，則會在數據目錄下記錄為mysql-bin.*（*代表0~9之間的某一個數字，來表示該日誌的序號）

bin-log還有其他一些附加選項參數：

max_binlog_size:來設置binlog的最大存儲上限，一般設為512M或1G，一般不能超過1G，當日誌達到該上限時，MySQL會重新創建一個日誌繼續記錄。不過偶爾也有超過該設置的binlog產生，一般都是因為在即將達到上限時，產生了一個較大的事務，為了保證事務的安全，mysql不會將同一個事務記錄到兩個binlog中。

binlog-do-db=db_name：如果有了該參數的顯示指定，MySQL會忽略針對其他數據庫執行的query，而僅僅記錄針對指定數據庫執行的query。

“binlog_ignore_db=db_name”與“binlog-do-db=db_name” 完全相反，他顯示指定忽略某個數據庫的binlog記錄，當指定了這個參數之後，MySQL會記錄指定數據庫以外所有的數據庫的binlog。

“binlog-do-db=db_name”與“binlog_ignore_db=db_name”兩個參數有一個共同的概念：

參數中的db_name不是值query語句更新的數據庫所在的數據庫，而是執行query的時候當前所處的數據庫。不論更新那個數據庫的數據，MySQL僅僅比較當前連接所處的數據庫（通過use db_name 切換後所在的數據庫）與參數設置的數據庫同名，而不會分析query語句所更新數據所在的數據庫。

其中，mysql_bin.index文件（binary log index）的功能是記錄所有Binary Log 的絕對路徑，保證MySQL 各種線程能夠順利的根據他找到所有需要的Binary Log 文件。

bin_cache_size=32768（默認）

bin_cache_size ：一個事務，在沒提交（uncommitted）的時候，產生的日誌，記錄到cache中：等到事務提交（committed）需要提交的時候，則把日誌持久化到磁盤。一般來說，如果我們數據庫中沒有什麽大事務，寫入也不是特別頻繁，2MB~4MB是一個合適的選擇。但是如果我們的數據庫大事務較多，寫入量較大，可以適當調高binlog_cache_size。同時，我們可以通過binlog_cache_use以及binlog_cache_disk_use來分析設置的binlog_cache_size是否足夠，是否有大量的binlog_cache由於內存大小不夠而使用臨時文件來緩存了

binlog_stmt_cache_size=32768 #當非事務語句使用二進制日誌緩存，但是超出binlog_stmt_cache_size時，使用一個臨時文件來存放這些語句。

binlog-format={ROW|STATEMENT|MIXED}#指定二進制日誌的類型，默認為MIXED。

1、STATEMENT模式（SBR）

每一條會修改數據的sql語句會記錄到binlog中。

優點是並不需要記錄每一行的數據變化，減少了binlog日質量，節約IO，提高性能，

缺點是在某些情況下會導致master-slave中的數據不一致（如sleep（）函數，last__insert_id()，以及user-defind functions（udf）等會出現問題）

2、ROW模式（RBR）

不記錄每條sql語句的信息，僅需記錄那條數據被修改了，修改成什麽樣了

缺點是會產生大量的日誌，使日誌暴漲。

3、MIXED模式（MBR）

以上兩種模式的混合使用，一般的復制使用STATEMENT模式保存binlog，對於STATEMENT模式無法復制的操作使用ROW模式保存binlog，MySQL會根據執行的sql語句選擇日誌保存方式。即交替使用行和語句、由MySQL服務器自行判斷。

其中基於行的定義格式數據量會大一些但是可以保證數據的準確性。

sync_binlog=10 #設定多久同步一次二進制日誌至磁盤文件中，0表示不同步，任何正數值都表示對二進制沒多少次寫操作之後同步一次。當autocommit的值為一時，每條語句執行都會引起二進制日誌同步，否則，每個事務的提交會引起二進制日誌的同步。

max_binlog_cache_size #二進制日誌緩存空間大小，5.5.9即以後的版本僅用於事務緩存，其上線由max_stmt_cache_size決定。

expire_log_days={0，99} #設定二進制日誌日誌的過期天數，超過次天數的二進制日誌將會自動刪除，默認為0，表示不啟用過期自動刪除功能。如果啟用此功能，自動刪除通常發生在MySQL啟動時或FLUSH日誌時。

當前二進制文件及所處位置

show binary logs；

查看二進制文件信息

show master status；

查看所有的二進制信息

show binlog event\G

查看指定日誌的二進制信息

show binlog events in 'mysql-bin.*' \G

**命令行下查看二進制日誌

mysqlbinlog “binlog_name”

刪除二進制日誌信息

purge {binary|master} logs {to ‘log_name’ | before datetime_expr}

例：purge binary logs to 'mysql-bin.000006'

刪除所有的二進制日誌（慎用）

reset master；

不建議生產環境使用此操作

事務日誌：（或稱redo日誌）

事務日誌（InnoDB特有的日誌）可以幫助提高事務的效率。使用事務日誌，存儲引擎在修改表的數據時只需要修改其內存拷貝，再把修改行為記錄到持久在硬盤上的事務日誌中，而不用每次都將修改的數據持久到硬盤。事務日誌采用追加的方式，因此寫日誌的操作是磁盤上一小塊區域內的順序I/O，而不像隨機I/O需要在多個地方移動磁頭，所以采用事務日誌的方式相對來說要快的多。事務日誌持久以後，內存中被修改的數據在後臺可以慢慢刷回磁盤。目前大多數的存儲引擎都是這樣實現的。

如果事務的修改已經記錄到了事務日誌並持久化，單數據本身還沒有寫會磁盤，此時系統崩潰，存儲引擎再重啟時能夠自動恢復這部分修改的數據。具有的恢復方式則視存儲引擎而定。

查看mysql已提供什麽養的搜索引擎

show engines

查看mysql當前默認的存儲引擎

show variables like '%storage_engine%'

查看某個表用了什麽引擎

show create teble 表名；

改變表的存儲引擎

create table 庫名.表明 engine=“innodb”

查看事務日誌的定義

show global variables like 'innodb_flush_log_at%'

#在事務提交時innodb是否同步日誌從緩沖區到文件中，

當這個值為1（默認值）之時，在每個事務提交時，日誌被寫到日誌文件，對日誌文件做到磁盤操作的刷新，性能會很差造成大量的磁盤I/O但這種方式最安全：

如果設為2，每次提交事務都會寫到日誌，但並不會執行刷操作。每秒定時刷到日誌文件,並不能保證100%每秒一定會刷新到磁盤，這要取決於進程的調度。

設置為0，日至緩沖每秒一次的被寫入到日誌文件，並且對日誌文件做到磁盤操作的刷新，但是在一個事物提交不做任何操作。

**刷寫的概念

刷寫其實是兩個操作，刷（flush）和寫（write），區分這兩個概念是很重要的。在大多數的操作系統中，把InnoDB的log buffer （內存）寫入日誌（調用系統調用write），只是簡單的把數據轉移到操作系統緩存中，操作系統緩存同樣指的是內存。並沒有持久化數據。

所以在0和2的時候，在崩潰或斷電的時候會丟失最後一秒的數據，因為這個時候數據只存在於操作系統的緩存。之所以說通常，可能會丟失不止一秒的數據的情況，比如說執行flush操作的時候阻塞了。

總結：

設為1當然是最安全的，但是性能也是最差的（相對於其他兩個參數而言，但不是不能接受）。如果對數據一致性和完整性要求不高，完全可以設為2，如果只要求性能，例如高並發寫的日誌服務器，設為0來獲得更高的性能。

慢查詢日誌： slow query log

顧名思義，慢查詢日誌中記錄的是執行時間較長的query，也就是我們常說的 slow query。慢查詢日誌采用的是簡單的文本格式，可以通過各種文本編輯器查看其中的內容。其中記錄了語句執行的時刻，執行所消耗的時間，執行用戶，連接主機等相關信息。

慢查詢日誌的作用：

慢查詢日誌是用來記錄執行時間較長的query，也就是我們常說的slow query 。

通過慢查詢日誌可以查出來那些查詢語句執行效率比較低，以便進行優化，一般建議開啟，他對服務器性能的影響微乎其微，但是可以記錄mysql服務器上執行了很長時間的查詢語句。可以幫助我們定位性能問題。mysql還提供了專門用來分析慢查詢日誌的工具程序mysqldumpslow，用來幫助數據庫管理人員解決可能存在的性能問題。

查看慢查詢日誌的定義

show global variables like '%slow_query_log%'

啟動和設置慢查詢日誌

方法一：通過my.cnf開啟慢查詢日誌

方法二：登陸MySQL服務器直接設置（使用set_query_log=1）

大多是版本都可以使用show variables like '%slow%' 或 show variables like '%long%'

其中

slow_query_log； off關閉狀態，on開啟狀態

slow_query_log_file: 慢查詢日誌存放地點

long_query_time： 設置時間值，時間以秒為單位，可以精確到微秒，如果超過了這個時間（默認是10秒）這個查詢語句將記錄到慢查詢日誌當中。設置為0的話，表示記錄所有的查詢。

註：

1、如果不指定路徑，默認存儲到mysql數據庫的數據文件下，如果不指定文件名，默認文件名為hostname-slow.log

2、將Unix時間轉成一個可讀的時間，可以使用date -d@日誌中的時間戳

3、mysqldumpslow 選項 參數

-s 是表示按照何種方式排序 ，c，t，l，r 分別是按照記錄次數，時間，查詢時間，返回的記錄數來排序，ac，at，al，ar表示相應的倒序。

-t ，是top n的意思，即為返回前面多少條的數據

-g，後面可以寫一個正則表達式，大小寫不敏感的

文件類型：

1、.frm 文件

與表相關的元數據（meta）信息都存放在“.frm”文件中，包括表結構的定義信息等。不論是什存儲引擎專用麽存儲引擎，每一個表都會有一個以表命名的.frm文件。存放在所屬數據庫的文件夾下面

2、MyISAM數據庫表文件：.MYD文件：表數據文件 .MYI：表索引文件

3、InnoDB采用表空間（tablespace）來管理數據，存儲表數據和索引

.ibd文件：但表表空間文件，每個表使用一個表空間文件（file per table），存放用戶數據庫表數據和索引

InnoDB共享表空間（即InnoDB文件集，ib-file set）：ibdata1、ibdata2等，存儲InnoDB系統信息和用戶數據庫表數據和索引，所有表共用

4、.ibd文件和ibdata文件

這兩種文件都是存放InnoDB數據的文件，之所以有兩種文件來存放InnoDB的數據（包括索引），是因為InnoDB的數據存儲方式能夠通過配置來決定是使用共享表空間存放存儲數據，還是獨享表空間來存儲數據。

獨享表空間：.ibd

共享表空間：.ibdata

ibdata文件可以通過

innodb_data_file_path 配置數據存放的總目錄

可以一次配置多個idbata文件，文件可以指定大小，也可以設為自動擴展，但只有最後一個ibdata文件可以設置為自動擴展。

必須重啟才能完成ibdata的添加工作

總結：

共享表空間以及獨占表空間都是針對數據的存儲方式而言的

共享表空間：某一個數據庫的所有表數據，索引文件全部放在一個文件中

獨占表空間：每一個都將會生成以獨立的文件方式來進行存儲，每一個表都有一個.frm表描述文件，還有一個。ibd文件，其中這個文件包括了單獨一個表的數據內容以及索引內容

兩者之間的優缺點：

共享表空間

優點：

可以放表空間分成多個文件存放到各個磁盤上。數據和文件放在一起方便管理

缺點：

所有數據和索引都放在一個文件中，多個表及索引在表空間中混合存儲，這樣對於一個表做了大量刪除操作後表空間中將會有大量的空隙，特別是對於統計分析，日值系統這類應用最不適合用共享表空間。

獨立表空間

優點：

1、每個表都有自己獨立的表空間

2、每個表的數據和索引都會存在自己的表空間中

3、可以實現單表在不同數據庫中移動

4、空間可以回收

a、Drop table 操作自動回收表空間，如果對於統計分析或是日值表，刪除大量數據以後，可以通過：altertable TableName engine = innodb;回縮不用的空間

b、對於使用獨立表空間的表，不管怎麽刪除，表空間的碎片不會太嚴重的影響性能，而且還有機會處理。

缺點：

單表增加過大，如超過100個G

相比之下，使用獨占表空間的效率和性能會更高一點

ON代表獨立表空間， OFF代表共享表空間

replication（存儲過程）相關文件

1、master.info文件

master.info文件存在於Slave端的數據目錄下，裏面存放了該Slave的Master端的相關信息，包括master的主機地址、連接用戶、連接密碼、連接端口、當前日誌位置，已經讀取到的日誌位置信息。

2、relay log 和relay log index

mysql-relay-bin.xxxxxn文件用於存放Slave端的I/O線程從master端所讀取到的binary log信息，然後由Slave端的SQL線程從該relay log 中讀取並解析相應的日誌信息，轉化成master所執行的SQL語句，然後再Slave端應用

mysql-relay-bin.index文件的功能類似於mysql-bin.index，同樣是記錄日誌的存放位置的絕對路徑，只不過她所記錄的不是binary log 而實relay log

3、relay-log.index文件

類似於master.info ，它存放通過Slave的I/O線程寫入到本地的relay log 的相關信息，共slave端的SQL線程及某些管理操作隨時能夠獲取當前復制的相關信息。

其他文件：

1、system config file

MySQL的系統配置文件一般是 my.cnf

2、pid file

pid file 是mysql應用程序在unix/linux環境下的一個進程文件

3、socket file

socket文件只在unix/linux 環境下才有，可直接只用socket文件來連接mysql，，速度比TCP的要快，但是只適用於mysql和應用在一臺PC上。

總結：

1、查看系統設置

show [global|session] variables [like_or_where]

2、運行狀態

show [global|session] status [like_or_where]

3、刷新日誌

flush log

MySQL錯誤日誌、二進制日誌、慢查詢日誌、事務日誌