MySQL體系結構之物理文件

1、MySQL日誌文件

mysql日誌文件及功能：

日誌文件	功能
錯誤日誌	記錄啓動、中止、運行過程當中mysqld時出現的問題
通用日誌	記錄創建客戶端鏈接和執行的語句
二進制日誌	記錄更改數據的全部語句，還用於複製
慢查詢日誌	記錄執行時間超過long_query_time秒的全部查詢

默認狀況下，mysql全部日誌均存儲於mysql數據目錄下。經過刷新日誌，能夠時mysqld強制關閉和打開日誌文件（或者在某些狀況下切換到下一個日誌）。

刷新日誌方法：

1）flush logs

2）mysqladmin flush-logs

3）mysqladmin refresh

一、錯誤日誌

1）做用：記錄mysqld啓動、中止以及mysql數據庫在運行過程當中發生的各類嚴重錯誤信息。當數據庫發生任何故障致使沒法重啓時，能夠參考錯誤日誌進行故障診斷。

2）位置：可使用--log-error[=file_name]參數選項來指定mysqld保存錯誤日誌文件的位置。若是沒有給定file_name文件位置，mysqld使用的錯誤日誌名爲host_name.err並默認保存在datadir指定的目錄下。

二、通用日誌

1）做用：查詢日誌記錄客戶端的全部語句（全部鏈接和語句都記錄到通用日誌），而binlog不記錄select語句。

2）位置：查詢日誌和慢查詢日誌均可以保存在文件或表中，並使用參數--log-output[=value]來進行控制，value的值能夠是table，file，none的一個或多個的組合，中間用逗號進行分割，分別表示日誌保存在表，文件，不保存在表或文件中，這裏的表指的是mysql庫總的general_log（慢查詢日誌是slow_log）表。其中none的優先級最高，好比--log-output=table,file表示日誌同時輸出到表和文件中，--log-output=table,none表示日誌不保存在表中。若是不顯示使用此參數，則表示日誌輸出到文件中。通常日誌輸出到表中要佔用更多的系統資源。

若是要啓用查詢日誌，能夠經過參數--general_log[={0|1}]和--general_log_file=file_name來進行控制。前者控制是否啓用查詢日誌（--general_log設置爲1或者不帶值均可以啓用查詢日誌，設置爲0表示關閉查詢日誌，不指定此參數表示不啓動查詢日誌），後者控制日誌文件的路徑。也可使用--log[=file_name]或-l [file_name]選項啓動它，若是沒有給出file_name，那麼默認值就是host_name.log。運行時能夠經過set global general_log on打開通用日誌。

若是沒有指定--general_log_file=file_name值，且沒有顯示設置--log_output參數，那麼日誌默認寫入datadir目錄下的，默認文件名爲host_name.log。這兩個參數都是global類型，能夠在啓動時或系統運行時動態修改。若是想在session級別控制日誌是否被記錄，則經過在session中設置參數sql_log_off爲on或off來進行控制。

查詢通用日誌位置：

mysql> show variables like 'gene%';

+------------------+--------------------------------------+

| Variable_name    | Value                                |

+------------------+--------------------------------------+

| general_log      | OFF                                  |

| general_log_file | /usr/local/mysql/data/chavinking.log |

+------------------+--------------------------------------+

2 rows in set (0.00 sec)

3）日誌內容的讀取：查詢日誌爲文本文檔格式，通常直接讀取就可。

4）通常狀況下不建議開啓查詢日誌功能，不然可能形成短期內磁盤佔用率猛增。

三、慢查詢日誌

1）概述：當參數slow_query_log=1時，慢查詢日誌記錄了全部執行時間超過參數long_query_time設置值而且掃描記錄數不小於min_examined_row_limit的全部sql語句的日誌（得到表鎖定的時間不能算做執行時間）。當沒有給出慢查詢日誌名時，默認爲主機名，後綴爲-slow.log，當給出了文件名，但不是絕對路徑，慢查詢日誌會記錄到mysql的數據目錄下。執行完語句而且釋放鎖後，便可記入慢查詢日誌，記錄順序能夠與執行順序不一樣。慢查詢日誌能夠查找執行時間長的語句，用於優化，它是MySQL數據中經常使用的性能優化工具。Long_query_time默認爲10秒，最小爲0，精度能夠到微秒。

通常兩類語句不記錄到慢查詢日誌中：管理語句和不使用索引進行查詢的語句。若是要監控這兩類SQL語句，能夠分別經過參數--log-slow-admin-statements和log_queries_not_using_indexes進行控制。

2）文件位置和格式：慢查詢日誌默認是關閉的，在mysql5.1.29前，當用--log-slow-queries[=file_name]選項啓動mysqld時，慢查詢日誌開始被記錄。和前幾種日誌同樣，若是沒有指定file_name的值，日誌將寫入datadir路徑，默認文件名爲host_name-slow.log。在mysql5.1.29後，--log-slow-queries參數廢棄，採用兩個新的參數進行替換：--slow_query_log[={0|1}]顯示指定慢查詢日誌狀態，若是不指定值或指定值爲1都會打開慢查詢；使用slow_query_log_file[=file_name]來指定慢查詢日誌路徑，另外還能夠指定--log-output參數指定日誌的輸出格式，默認輸出到文件。須要注意的是若是選擇輸出到表，則表中的記錄的慢查詢時間只能精確到秒，而日誌文件中能夠精確到微秒。

3）日誌文件的讀取：慢查詢日誌文件是存文本方式存儲，能夠直接讀取。也能夠經過mysqldumpslow工具（../bin/mysqldumpslow faspdev-slow.log）對慢查詢日誌進行彙總處理。慢查詢日誌一般用來定位mysql服務中sql問題，默認建議打開慢查詢日誌，並按期查看分析。

4）慢查詢日誌在mysql性能優化中的做用詳解：

4.1）慢查詢日誌格式：

mysql慢查詢標準：

query_time：查詢耗時

rows_examined：檢查多少條記錄

rows_sent：返回多少行記錄

mysql使用以上幾點大體衡量sql成本。

其餘信息包括以下：

time：執行sql開始時間

lock time：等待table lock的時間，注意innodb行鎖等待不會反應在這裏。

user@host：執行查詢的用戶和客戶端ip

如下是一個慢查詢例子：

# Time: 170122 13:53:17 # User@Host: root[root] @ localhost []  Id:     1 # Query_time: 9.839503  Lock_time: 0.000159 Rows_sent: 0  Rows_examined: 524288 SET timestamp=1485064397; insert into column_charset  select * from column_charset;

通常執行時間最長的sql是須要優化的，若是檢查了大量數據而只返回少許數據，則意味着質量不佳。須要注意的是慢查詢日誌裏的慢查詢不必定就是不良sql，還可能受其餘查詢影響，或者受到系統資源限制致使的。

4.2）如何識別須要關注的sql：

確認已經開啓了慢查詢日誌，而且設置了合理的閾值。如下命令能夠查看是否啓用慢查詢日誌以及慢查詢日誌路徑：

mysql> show variables like '%slow_query_log%';

+---------------------+------------------------------------------- ------------------------+

| Variable_name       | Value                                      |

+---------------------+--------------------------------------------------------------------+

| slow_query_log      | OFF                                        |

| slow_query_log_file | /usr/local/mysql5631/data/faspdev-slow.log |

+---------------------+-------------------------------------------------------------------+

如下命令能夠查看全局變量long_query_time參數的值，全部超過該值得sql都將記錄到慢查詢日誌中：

mysql> show variables like 'long_query_time';

+-----------------+-----------+

| Variable_name   | Value     |

+-----------------+-----------+

| long_query_time | 1.000000 |

+-----------------+-----------+

1 row in set (0.00 sec)

在mysql參數文件中開啓慢查詢日誌設置以下：

[mysqld]

slow_query_log=1

slow_query_log_file=/usr/local/mysql/data/log/slowquery.log

long_query_time=0.5

mysql 5.0慢查詢參數是不同的，且須要重啓後才能夠生效，相關參數爲log_slow_queries和slow_launch_time。

參數log-queries-not-using-indexes用於指定若是沒有使用到索引或雖然使用了索引但仍然遍歷了全部記錄，就將其記錄下來，默認此參數是關閉的。

4.3）使用工具分析慢查詢日誌

若是慢查詢日誌內容比較多，對於分析是比較麻煩的，通常有如下兩種辦法能夠參考：

u 調整閾值

u 使用命令、腳本、工具進行分析，如mysqldumpslow、pt-query-digest等。

A. 使用操做系統命令進行分析：

可使用shell命令進行統計分析，如grep、awk、wc，可是這些工具不容易實現高級功能。

awk '/^#Time:/{print $3,$4,c;c=0}/^#User/{c++}' mysql-slow.log > /mnt/slowquery.log

B. 使用mysqldumpslow工具進行分析：

mysqldumpslow工具是官方自帶的，此工具能夠得到日誌中的查詢摘要。如下是mysqldumpslow工具使用幫助：

$mysqldumpslow --help Usage: mysqldumpslow [ OPTS... ] [ LOGS... ] Parse and summarize the MySQL slow query log. Options are   --verbose    verbose   --debug      debug   --help       write this text to standard output   -v           verbose   -d           debug   -s ORDER     what to sort by (t, at, l, al, r, ar etc), 'at' is default   -r           reverse the sort order (largest last instead of first)   -t NUM       just show the top n queries   -a           don't abstract all numbers to N and strings to 'S'   -n NUM       abstract numbers with at least n digits within names   -g PATTERN   grep: only consider stmts that include this string   -h HOSTNAME  hostname of db server for *-slow.log filename (can be wildcard),                default is '*', i.e. match all   -i NAME      name of server instance (if using mysql.server startup script)   -l           don't subtract lock time from total time

查詢時間最長的10個sql：

mysqldumpslow -t 10 mysql-slow.log

查詢訪問次數最多的10個sql命令：

mysqldumpslow -s c -t 10 mysql-slow.log

查詢訪問記錄最多的10條sql命令：

mysqldumpslow -s r -t 10 mysql-slow.log

4.4）如下是mysql運行狀態下設置慢查詢日誌的例子

mysql> show variables like 'long_query_time'; +-----------------+-----------+ | Variable_name   | Value     | +-----------------+-----------+ | long_query_time | 10.000000 | +-----------------+-----------+ 1 row in set (0.00 sec) mysql> set long_query_time=2; Query OK, 0 rows affected (0.00 sec)

mysql> show variables like '%slow_query_log%'; +---------------------+--------------------------------------------+ | Variable_name       | Value                                      | +---------------------+--------------------------------------------+ | slow_query_log      | OFF                                        | | slow_query_log_file | /usr/local/mysql5631/data/faspdev-slow.log | +---------------------+--------------------------------------------+ 2 rows in set (0.00 sec) mysql> set global slow_query_log=1; Query OK, 0 rows affected (0.00 sec)

四、binlog日誌文件

1）做用：Binlog記錄了數據庫全部的ddl語句和dml語句，但不包括select語句內容，語句以事件的形式保存，描述了數據的變動順序，binlog還包括了每一個更新語句的執行時間信息，binlog主要做用是用於恢復數據，所以binlog對於災難恢復和備份恢復來講相當重要。至關於oracle數據庫中的archivelog文件。

binlog還用於實現mysql主從複製。

二進制日誌文件記錄了數據庫的變動過程，對於數據庫的安全性和完整性起着相當重要的做用。

2）位置和格式：當用--log-bin[=file_name]選項啓動時，mysqld開始將數據庫變動狀況寫入日誌文件。若是沒有給出file_name值，默認名爲主機名-bin。若是給出了文件名，但不包含路徑，則文件默認被寫入datadir參數指定路徑。

mysqld將在每一個binlog日誌名後添加一個數字擴展名，每次要啓動服務器或刷新日誌時，該數字將會增長，若是當前日誌大小達到了max-binlog-size參數設置的值，那麼mysqld會自動建立新的二進制日誌。

mysqld還將建立一個binlog索引文件，其中包含了全部binlog文件的文件名，默認該索引文件與binlog文件名相同，擴展名爲.index。當mysqld運行時，不能夠手工編輯該索引文件，這樣可能致使mysqld異常。當rm刪除binlog後，你也許不得不手工編輯索引文件。

3）binlog日誌格式

mysql有兩種記錄命令方式，一種是語句級（binlog_format=statement），一種是行級（binlog_format=row），建議命令格式設置爲混合模式（binlog_format=mixed），這在大部分模式下試用，它在通常狀況下試用語句級記錄，可是在一些特殊狀況下試用行級記錄，這增長了複製的健壯性。

Mysq5.5中，二進制日誌格式分爲3種：statement，row和mixed，能夠在啓動數據庫時經過參數--binlog_format進行設置，這3種格式區別以下：

3.1）statement：

Mysql5.1以前的版本都採用這種方式，binlog日誌中記錄的都是語句（基於語句級的日誌裏包含了原始執行的sql語句，還有其餘信息，如執行語句的線程id，語句執行的時間戳，執行所消耗時長），每一條對數據庫形成修改的語句都會記錄在日誌中，經過mysqlbinlog工具，能夠清晰的看到每條語句的文本。主從複製時，從庫的日誌解析爲原文本在從庫中執行。優勢是日誌量小，清晰易懂，對io壓力小，缺點是某些狀況下slave的日誌複製會出差。

3.2）row：

Mysql5.1.11以後出現的。它將每一行變動記錄到日誌中，而不是記錄sql語句（記錄行的更改信息而不是語句）。優勢是記錄每一行數據變化的細節，不會出現slave模式下某些狀況沒法複製的狀況。缺點是日誌量大，對io影響較大。經過mysqlbinlog默認看到的都是通過base-64編碼的信息，mysqlbinlog加參數-verbose（或-v）將會生成帶註釋的語句，若是連續兩次使用這個參數（如-v -v），則生成字段類型、長度、是否爲null等屬性信息。

通常而言，row模式更爲健壯，而statement級別若是應用了mysql的一些額外特性，好比存儲過程、觸發器，則可能致使複製異常，因此，若是使用語句級記錄，那麼須要保持mysql數據庫應用的簡單性，即只用核心功能便可。

3.3）mixed：

這是目前mysql的默認binlog日誌格式，即混合了statement和row兩種日誌。默認狀況下采用statement，可是在一些特殊狀況下采用row方式記錄日誌。此種模式利用statement和row的優勢，而儘可能避開他們的缺點。

注意：能夠在global和session級別對binlog日誌的格式進行修改。

4）日誌文件的讀取

因爲binlog以二進制方式存儲，不能直接讀取，所以須要使用mysqlbinlog工具進行日誌分析，語法：mysqlbinlog log-file。

例：

4.1）以binlog方式啓動數據庫：

[root@faspdev bin]# ./mysqld_safe --user=mysql --log-bin=binlog-test

4.2）執行dml語句：

mysql> delete from t1;

Query OK, 2 rows affected (0.02 sec)

4.3）mysqlbinlog查看binlog內容：

[root@faspdev data]# ../bin/mysqlbinlog binlog-test.000001 /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!40019 SET @@session.max_insert_delayed_threads=0*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #161111 17:45:52 server id 1  end_log_pos 120 CRC32 0x5bfb8e4f Start: binlog v 4, server v 5.6.31-log created 161111 17:45:52 at startup # Warning: this binlog is either in use or was not closed properly. ROLLBACK/*!*/; BINLOG ' UJMlWA8BAAAAdAAAAHgAAAABAAQANS42LjMxLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABQkyVYEzgNAAgAEgAEBAQEEgAAXAAEGggAAAAICAgCAAAACgoKGRkAAU+O +1s= '/*!*/; # at 120 #161111 17:47:29 server id 1  end_log_pos 199 CRC32 0x3f0abe26 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1478857649/*!*/; SET @@session.pseudo_thread_id=1/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/; SET @@session.sql_mode=1075838976/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C utf8 *//*!*/; SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; BEGIN /*!*/; # at 199 #161111 17:47:29 server id 1  end_log_pos 287 CRC32 0x78e57a7e Query thread_id=1 exec_time=0 error_code=0 use `test`/*!*/; SET TIMESTAMP=1478857649/*!*/; delete from t1 /*!*/; # at 287 #161111 17:47:29 server id 1  end_log_pos 318 CRC32 0x0b2d7e98 Xid = 9 COMMIT/*!*/; DELIMITER ; # End of log file ROLLBACK /* added by mysqlbinlog */; /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

若是日誌格式是row，mysqlbinlog解析的文件是沒法讀懂的字符，能夠加-v或-v -v進行查看。

5）默認狀況下，並非每次寫入時都將binlog與磁盤同步，所以操做系統或機器發生故障，那麼binlog中最後的語句有可能會丟失。要防止這種狀況發生，能夠設置sync_binlog全局變量爲n（1爲最安全的值，同時也是最慢的），使binlog每n此寫入就與磁盤作同步。

6）日誌文件的刪除

查看binlog方法：

mysql> show binary logs;

6.1）方法1：reset master刪除全部的binlog日誌文件，刪除後的日誌文件從1開始編號。

mysql> reset master;

Query OK, 0 rows affected (0.00 sec)

6.2）方法2：使用purge binary logs命令刪除部分binlog文件：

mysql> purge binary logs to 'mysql-bin.000001';

Query OK, 0 rows affected (0.03 sec)

6.3）方法3：purge master logs to ‘mysql-bin.******’命令，該命令刪除‘******’編號以前的全部日誌文件。

6.4）方法4：purge master logs before ‘yyyy-mm-dd hh24:mi:ss’命令，該命令刪除‘yyyy-mm-dd hh24:mi:ss’日期以前的全部日誌。

6.5）設置參數--expire_logs_days=#,此參數含義是設置日誌過時天數， 過了指定天數後的日誌將會被自動刪除，這樣有利於減小DBA管理日誌的工做量。

7）mysqlbinlog解析：

u # at 199

u #161111 17:47:29 server id 1  end_log_pos 287

u # Query thread_id=1 exec_time=0 error_code=0

8）binlog管理相關參數

8.1）--binlog-do-db=db_name:該參數告訴主服務器，若是當前的數據庫是db_name，應該將其記錄到binlog中，其餘沒有被指定的數據庫將被忽略，可屢次使用，對多個數據庫進行定義。

8.2）--binlog-ignore-db=db_name:改參數告訴主服務器，若是當前數據庫爲db_name，則不記錄binlog，其餘沒有指定的數據庫變化將記錄binlog中，可屢次使用，對多個數據庫進行定義。

8.3）--innodb-sage-binlog:該參數常常和--sync-binlog=N（沒寫N第二天志同步磁盤）一塊兒配合使用，使得事務在日誌中的記錄更加安全。

8.4）Set sql_log_bin=0：具備super權限的客戶端能夠經過此語句禁止將本身的語句記錄二進制文件，這個選項在某些環境下是有用的，好比主主切換，或者mysql版本升級，可是使用必定倍加當心，省得形成slave環境下的數據不一致。

五、日誌文件維護

不少生產環境，日誌文件能夠佔用大量的磁盤空間，所以，須要對日誌文件進行按期清理操做，mysql服務器固然也不例外。

l 對於錯誤日誌文件，通常不會太大，所以生產上注意一下就能夠了。

l 通用日誌通常生產不開啓，所以也不存在清理一說。

l 慢查詢日誌在慢查詢不少的狀況下可能變得很大，能夠手工清理或編寫腳本管理。

l binlog日誌文件能夠設置合適的過時策略，如expire-logs-days=10，表示設置binlog過時時間爲10天。expires-logs-days設置會在運行flush logs命令後觸發刪除過時日誌，注意，不能使用rm刪除binlog日誌文件，這可能致使你執行日誌清理命令失敗。mysql 5.6能夠設置保留binlog日誌文件大小，避免磁盤對填滿。

2、innodb數據文件和日誌文件

一、如下簡單介紹mysql數據目錄下的文件：

1）db.opt

數據庫結構定義和設置

2）*.frm

數據表的結構定義

3）*.MYD

Myisam引擎表數據

4）*.MYI

Myisam引擎索引數據

5）ibdata*

Innodb表空間數據文件

若是將innodb_file_per_table設置爲1，那麼innodb數據表能夠各自存儲爲一個文件，這種模式成爲獨立表空間。若是將innodb_file_per_table設置爲0，那麼innodb數據則能夠統一存儲在一個共享表空間裏。

6）ib_logfile*

Innodb重作日誌文件

7）*.idb

Innodb數據和索引。

8）*.trg

觸發器

二、innodb數據文件和日誌文件

若是沒有再參數文件中指定innodb相關參數，那麼mysql將會在data目錄下建立一個大小爲10m的ibdata1文件和大小5m的兩個ib_logfile*文件。這種設置對於生產而言過小，通常建議設置logfile爲256m，數據文件初始大小1g~5g，而且設置自動增加。

參數配置樣例：

Innodb_data_file_path=ibdata1:1000m:autiextend

Innodb_log_file_size=256m

Innodb_data_file_path的值能夠設置爲1個或多個列表。若是要命名一個以上的數據文件，請用「;」分隔它們。其語法格式爲：Innodb_data_file_path=datafile01:size[;datafile02:size;...]。

例如：Innodb_data_file_path=datafile01:2000m;datafile02:2000m;datafile03:2000m:autoextend

其中autoextend及其後屬相只能用於Innodb_data_file_path列表中最後一個數據文件，針對於最後一個數據文件，若是innodb共享表空間耗盡後，就會擴展最後一個數據文件，默認擴展大小爲8m。

1）innodb獨立表空間和共享表空間

共享表空間使用簡單，方便維護，可是也存在缺點，使用貢獻表空間明顯的缺點是不能快速回收刪除大表的空間，io操做可能會消耗更多的資源等待。而獨立表空間是大部分DBA推薦使用的方式，它剛好在這一點彌補了共享表空間不足。Innodb下使用獨立表空間，每一個表都有它本身的表空間。

開啓獨立表空間方式：

在my.cnf文件中添加以下參數，重啓mysql實例便可生效：

[mysqld]

innodb_file_per_table

重啓實例後，innodb將會把新建立的表存儲到數據目錄下的文件tb1_name.ibd中，這相似域myisam存儲引擎所作的事，可是myisam把表分紅數據文件tb1_name.MYD和索引文件tb1_name.MYI。對於innodb，數據和索引會放在一塊兒，都存放到.ibd文件中，不過tb1_name.frm文件照舊會被建立。

在my.cnf文件中刪除了innodb_file_per_table行，重啓實例後，innodb新建立的表會存儲在共享表空間裏，就是說innodb_file_per_table這個參數僅影響表的建立位置。innodb使用獨立表空間，也仍然有一部分數據在共享表空間裏。

相對於myisam引擎管理的表，咱們不能隨意移動.ibd文件，這是由於表定義是被存儲在innodb共享表空間裏的，而innodb必須保持事務id和事務日誌順序號的一致性。

2）innodb增長數據文件

手動增長一個innodb數據文件時須要重啓實例。爲innodb存儲引擎管理表添加數據文件須要修改my.cnf參數文件，把innodb_data_file_path參數指定添加的數據文件及其初始大小和相關參數。注意當你添加一個數據文件到innodb_data_file_path時，須要肯定它不存在，當你重啓實例時，innodb會自動建立這個數據文件。添加innodb數據文件須要首先計算當前innodb_data_file_path中最後一個數據文件大小，而後估計一個近似值給它，再添加新的數據文件。Innodb數據文件只有最後一個能夠設置爲自動擴展。

3）改變innodb重作日誌大小

不要試圖經過直接更改配置文件來設置innodb事務日誌大小，這會致使不能啓動數據庫。若是想要改變innodb事務日誌的數量和大小，必須正常關閉mysql實例，而後複製舊日誌文件到一個安全的地方作備份，而後從日誌文件目錄刪除全部的舊日誌文件，以後更改my.cnf參數文件改變日誌文件配置，並再次啓動mysql實例。Mysqld在啓動時會發現沒有重作日誌文件，而後告訴你它正在建立一個新的日誌文件。

更改innodb事務日誌步驟：

l 乾淨關閉mysql實例

l 使用mv命令轉移innodb重作日誌文件。

l 修改my.cnf配置文件，更改innodb_log_file_size

l 啓動mysql實例

注意，舊版本mysql服務器重作日誌總大小不能超過4g，在mysql5.6之後，限制擴展到521g。

4）innodb的undo區域

Undo區域也稱爲undo空間或undo表空間，是innodb設計的一塊特殊存儲區域，它保存了被活動事務更改的數據的副本（鏡像），若是一個事務須要查看原來的數據（知足一致性讀），那麼能夠從undo區域中得到未被更改的數據。默認狀況下，undo區域也是在innodb共享表空間內。Mysql5.6之後提供了選項，能夠把undo表空間獨立到表空間，這樣就能夠進行熱點塊的io優化，提高性能。

若是undo表空間暴漲，出現這種狀況多是由於負載比較大，或者存在長時間未提交的事務（長事務）。

對於寫操做比較頻繁的應用，innodb清理線程的速度可能會跟不上，從而致使undo表空間愈來愈大，能夠經過設置innodb_max_purge_lag參數來避免undo空間過分增大。Innodb事務系統維持一個事務列表，該列表記錄被update或delete操做表示爲刪除的索引記錄。這個列表的長度爲purge_lag。當purge_lag超過了nnodb_max_purge_lag時，每一個dml語句都被延遲必定時間。

Undo空間裏保存了數據的前鏡像，這是知足一致性讀的根本緣由，同時也是災難恢復的重要角色（即回滾）。

三、臨時文件

Mysql臨時文件做用相似但不等同於oracle臨時表空間。Mysql使用環境變量TMPDIR的值做爲保存臨時文件的目錄。若是未設置，則默認使用系統的默認值，通常爲/tmp，/var/tmp，/usr/tmp。可使用--tmpdir參數在啓動時指定mysql臨時目錄，或者在my.cnf文件中指定tmpdir參數進行分配。

若是mysql服務器正在做爲複製服務器使用，那麼不能將mysql臨時路徑指向基於內存的文件系統目錄或者主機重啓會清空的目錄，不然可能形成複製失敗。Mysql隱含建立全部的臨時文件。進行排序操做時，mysql會使用一個或多個臨時文件。必定要保證臨時目錄空間夠用。一些普通的數據庫操做都有可能建立臨時文件用於維護數據庫內的數據結構，alter table會在原表所在目錄下建立臨時表。

四、mysql套接字文件

服務器用來與本地客戶端進行通訊的linux套接字文件（也稱爲socket文件）默認位置是/tmp/mysql.sock。Scoket文件不建議放置在/tmp目錄下，能夠將其單獨指定存儲位置，咱們能夠經過my.cnf配置文件指定mysql socket文件存儲路徑，下面是my.cnf中定義socket儲存路徑：

[mysqld]

Socket=/opt/mysql/mysql.socket

[client]

Socket=/opt/mysql/mysql.socket

Mysql服務器必定要保留root的除了socket外的其餘登陸方式，好比經過127.0.0.1的root登陸帳號，以防止socket文件被刪除致使沒法登陸mysql數據庫的窘境。

3、MySQL災難恢復過程

一、預寫日誌和undo表空間

mysql靠預寫日誌（innodb事務日誌）來保證數據持久性，也就是說數據文件不會先被寫入，而是先寫日誌文件。innodb髒數據存在於innodb_buffer_pool裏，它會按照必定的機制批量寫入磁盤，這樣能夠提升吞吐率。

mysql宕機後的實例恢復過程：首先mysql找到事務日誌中的某個點，從該點開始重作redo中的事務，在應用了全部redo日誌後，根據undo區域肯定哪些事務須要回滾，而後回滾哪些沒有提交的事務，簡單理解，mysql災難恢復過程就是根據redo重作日誌，而後根據undo回退事務。

innodb事務日誌很大程度上決定了數據的安全性，日誌的持久性決定了災難恢復後丟失多少數據！mysql能夠經過參數控制commit時寫入事務日誌的頻率，一般有如下3種狀況：

1）innodb_flush_log_at_trx_commit=1

每次commit時都寫入磁盤，這樣理論上發生故障時咱們只丟失一個事務。

2）innodb_flush_log_at_trx_commit=2

每次commit，只寫日誌緩存到操做系統緩衝，但不刷新磁盤，innodb每秒刷新磁盤一次，因此故障丟失的是最近1秒的數據。生產環境建議這樣設置。

3）innodb_flush_log_at_trx_commit=0

每秒把日誌緩衝的內容寫入到日誌文件，而且刷新到磁盤，但commit時什麼也不作。

二、雙寫緩衝

數據文件的寫操做，可能會將塊寫壞，mysql設計了一個數據存儲區域雙寫緩衝，innodb使用雙寫緩衝來確保數據的安全，避免塊損壞。雙寫緩衝是innodb表空間的一個特殊區域，主要用於寫入頁的備份，而且是順序寫入的。當innodb刷新數據時，首先寫入雙寫緩衝，而後寫入數據文件。這樣既可確保全部寫操做的原子性和持久性。

崩潰重啓後，innodb會檢查每一個塊的校驗和，判斷塊是否損壞，若是寫入雙寫緩衝的是壞塊，那麼顯然沒有寫入實際數據文件，那麼用數據文件的塊恢復雙寫緩衝；若是寫入了雙寫緩衝，可是數據文件中的是壞塊，那麼使用雙寫緩衝中的塊恢復實際數據文件中的塊。這樣的機制提供了雙層的安全保障，可是缺點是增長了io。

對於讀取操做，innodb經過頁校驗和來保證數據的存取，每頁在內存中都先算好一個校驗值，放在文件頭部，寫入的時候先寫校驗值，讀的時候也會校驗一下校驗值。

4、mysql參數文件及參數修改方法

MySQL數據庫初始化參數由參數文件來設置，若是沒有設置參數文件，mysql就按照系統中參數的默認值來啓動。在windows和linux上，參數文件能夠被放在多個位置，數據庫啓動時按照不一樣的順序來搜索，若是多個位置都有參數文件，則搜索順序靠後的參數文件中的參數將覆蓋前的參數。

表：linux下mysql參數文件讀取順序：

參數文件名	目的
/etc/my.cnf	全局選項
$MYSQL_HOME/my.cnf	服務器相關選項
Default-extra-file	用--Default-extra-file=path選項指定的文件，若是該文件存在的話
~/.my.cnf	用戶相關選項

Mysql安裝上述順序尋找參數文件，若是多個文件同時存在，那麼文件中指定的後讀取的選項要優先於先讀取的選項，因此數據目錄或安裝目錄下的配置文件都有可能生效，因此理論上在數據目錄或安裝目錄下放置一個my.cnf文件便可。Mysql啓動時能夠指定--datadir用於指定數據路徑，可是此選項對於查詢參數文件無效，由於在讀取--datadir以前mysql服務器就已經讀取了配置文件了。屢次指定一個選項，後出現的將覆蓋先出現的值，所以命令行中經過set修改的選項優先級最高。

經過以下命令能夠列出mysqld讀取參數文件的優先順序：該命令不能在生產環境隨意運行

$mysqld --verbose --help |grep my.cnf

/etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf

Mysql參數能夠在3個級別進行更改：

1）session級別：set

2）全局級別：set global

3）永久級別：my.cnf

附：一份生產可用的mysql配置文件（my.cnf）示例（測試庫mysql 5.6.24）：

[client] #客戶端選項設置 port = 3306 socket = /opt/mysql-5.6.24/data/mysql.socket #設置客戶端和鏈接字符集 default_character_set = utf8 [mysqld] #服務器端選項設置 # innodb設置 default_storage_engine = InnoDB innodb_strict_mode = 1 innodb_buffer_pool_size = 256M      #mysql數據庫服務器，該值可設爲物理內存的50%-80%之間 innodb_stats_on_metadata = 0 innodb_file_format = Barracuda innodb_data_file_path=ibdata1:10m:autoextend innodb_flush_method = O_DIRECT innodb_log_files_in_group = 2 innodb_log_file_size = 16M innodb_log_buffer_size = 8M innodb_file_per_table = 1 innodb_max_dirty_pages_pct = 60 innodb_io_capacity = 200 innodb_flush_log_at_trx_commit = 2 # 基本設置 basedir = /opt/mysql-5.6.24 datadir = /opt/mysql-5.6.24/data port = 3306 server_id = 19900315 tmpdir = /opt/mysql-5.6.24/tmp socket = /opt/mysql-5.6.24/tmp/mysql.socket Pid-file = /opt/mysql-5.6.24/data/mysql.pid skip-name-resolve = 1 skip-external-locking = 1 max_connect_errors = 500 max_connections = 1000 relay-log = mysql-relay-bin log-slave-updates = 1 skip_slave_start = 1 read_only = 0 key_buffer_size = 8M tmp_table_size = 8M max_heap_table_size = 8M query_cache_type = 0 query_cache_size = 0 thread_cache_size = 1024 open_files_limit = 65535 table_open_cache = 1024 max_allowed_packet = 16M gtid-mode = ON enforce-gtid-consistency = 1 lower_case_table_names=1 log-bin-trust-function-creators plugin-load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so" replicate-ignore-table = mysql.ibbackup_binlog_marker slave-skip-errors = ddl_exist_errors relay-log-info-repository = TABLE relay_log_recovery = 1 master_info_repository = TABLE # 服務器字符集設置 character_set_server = utf8 # error log設置 log_error = /opt/mysql-5.6.24/data/mysql.err # slow log設置 slow_query_log = 1 slow_query_log_file = /opt/mysql-5.6.24/data/mysql-slow.log long_query_time = 0.5 # binlog設置 binlog_format = mixed log-bin = /opt/mysql-5.6.24/logs/mysql-bin sync_binlog = 2 max_binlog_size = 16M expire_logs_days = 10 #others設置 join_buffer_size = 128M sort_buffer_size = 2M read_rnd_buffer_size = 2M sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES