本章將分析構(gòu)成MySQL數(shù)據(jù)庫(kù)和InnoDB存儲(chǔ)引擎表的各種類(lèi)型文件顶瞳。 這些文件有以下這些：

1.參數(shù)文件 ：告訴MySQL實(shí)例啟動(dòng)時(shí)在哪里可以找到數(shù)據(jù)庫(kù)文件嚼隘， 并且指定某些初始化參數(shù)， 這些參數(shù)定義了某種內(nèi)存結(jié)構(gòu)的大小等設(shè)置屯曹， 還會(huì)介紹各種參數(shù)的類(lèi)型脊另。

2.日志文件 ：用來(lái)記錄 MySQL實(shí)例對(duì)某種條件做出響應(yīng)時(shí)寫(xiě)入的文件， 如錯(cuò)誤日志文件纹坐、 二進(jìn)制日志文件、 慢查詢(xún)?nèi)罩疚募?查詢(xún)?nèi)罩疚募取?/p>

3. socket文件： 當(dāng)用UNIX域套接字方式進(jìn)行連接時(shí)需要的文件列肢。

4.pid文件： MySQL實(shí)例的進(jìn)程ID文件恰画。

5.MySQL表結(jié)構(gòu)文件： 用來(lái)存放MySQL表結(jié)構(gòu)定義文件。

6.存儲(chǔ)引擎文件： 因?yàn)镸ySQL表存儲(chǔ)引擎的關(guān)系瓷马， 每個(gè)存儲(chǔ)引擎都會(huì)有自己的文件來(lái)保存各種數(shù)據(jù)拴还。 這些存儲(chǔ)引擎真正存儲(chǔ)了記錄和索引等數(shù)據(jù)。 本章主要介紹與lnnoDB有關(guān)的存儲(chǔ)引擎文件欧聘。

3.1 參數(shù)文件

? ??????在第1章中已經(jīng)介紹過(guò)了片林， 當(dāng)MySQL實(shí)例啟動(dòng)時(shí)， 數(shù)據(jù)庫(kù)會(huì)先去讀一個(gè)配置參數(shù)文件怀骤， 用來(lái)尋找數(shù)據(jù)庫(kù)的各種文件所在位置以及指定某些初始化參數(shù)费封， 這些參數(shù)通常定義了某種內(nèi)存結(jié)構(gòu)有多大等。 在默認(rèn)情況下蒋伦， MySQL實(shí)例會(huì)按照一定的順序在指定的位 置進(jìn)行讀取弓摘， 用戶(hù)只需通過(guò)命令mysql--help I grep my.cnf來(lái)尋找即可。

3.1.1 什么是參數(shù)

? ??????簡(jiǎn)單地說(shuō)痕届，可以把數(shù)據(jù)庫(kù)參數(shù)看成一個(gè)鍵/值(key/value)對(duì)韧献。第2章已經(jīng)介紹了一個(gè)對(duì)于lnnoDB 存儲(chǔ)引擎很重要的參數(shù)innodb_ buffer _pool_ size。如我們將這個(gè)參數(shù)設(shè)置為lG, 即innodb_ buffer _pool_ size= 1G 研叫。這里的 “鍵” 是innodbb uffer _pool_size, "值” 是lG, 這就是鍵值對(duì)锤窑。

3.1.2 參數(shù)類(lèi)型

? ??????MySQL數(shù)據(jù)庫(kù)中的參數(shù)可以分為兩類(lèi)：

1.動(dòng)態(tài)(dynamic)參數(shù)

2.靜態(tài)(static)參數(shù)

????????動(dòng)態(tài)參數(shù)意味著可以在MySQL實(shí)例運(yùn)行中進(jìn)行更改， 靜態(tài)參數(shù)說(shuō)明在整個(gè)實(shí)例生命周期內(nèi)都不得進(jìn)行更改嚷炉， 就好像是只讀(read only)的渊啰。 可以通過(guò)SET命令對(duì)動(dòng)態(tài)的參數(shù)值進(jìn)行修改， SET的語(yǔ)法如下：

????????這里可以看到global和session關(guān)鍵字申屹， 它們表明該參數(shù)的修改是基于當(dāng)前會(huì)話(huà)還是整個(gè)實(shí)例的生命周期绘证。 有些動(dòng)態(tài)參數(shù)只能在會(huì)話(huà)中進(jìn)行修改， 如autocommit ; 而有些參數(shù)修改完后哗讥， 在整個(gè)實(shí)例生命周期中都會(huì)生效迈窟， 如binlog_cache_size; 而有些參數(shù)既可以在會(huì)話(huà)中又可以在整個(gè)實(shí)例的生命周期內(nèi)生效。

3.2日志文件

????????日志文件記錄了影響MySQL數(shù)據(jù)庫(kù)的各種類(lèi)型活動(dòng)忌栅。 MySQL數(shù)據(jù)庫(kù) 中常見(jiàn)的日志 文件有：

錯(cuò)誤日志(errorlog）

二進(jìn)制日志Cbinlog)

慢查詢(xún)?nèi)罩?slow query log)

查詢(xún)?nèi)罩荆╨og)

3.2.1 錯(cuò)誤日志

????????錯(cuò)誤日志文件對(duì)MySQL的啟動(dòng)车酣、 運(yùn)行、 關(guān)閉過(guò)程進(jìn)行了記錄索绪。 MySQLDBA在遇到問(wèn)題時(shí)應(yīng)該首先查看該文件以便定位問(wèn)題湖员。 該文件不僅記錄了所有的錯(cuò)誤信息， 也記錄一些警告信息或正確的信息瑞驱。 用戶(hù)可以通過(guò)命令SHOW VARIABLES LIKE'log_error' 來(lái)定位該文件

3.2.2慢查詢(xún)?nèi)罩?/b>

? ??????3.2.1小節(jié)提到可以通過(guò)錯(cuò)誤日志得到一些關(guān)于數(shù)據(jù)庫(kù)優(yōu)化的信息娘摔， 而慢查詢(xún)?nèi)罩?slow log)可幫助OBA定位可能存在問(wèn)題的SQL語(yǔ)句，從而進(jìn)行SQL語(yǔ)句層面的優(yōu)化唤反。例如凳寺， 可以在MySQL啟動(dòng)時(shí)設(shè)一個(gè)闊值鸭津，將運(yùn)行時(shí)間超過(guò)該值的所有SQL語(yǔ)句都記錄到慢查詢(xún)?nèi)罩疚募小BA每天或每過(guò)一段時(shí)間對(duì)其進(jìn)行檢查肠缨， 確認(rèn)是否有SQL語(yǔ)句需要進(jìn)行優(yōu)化逆趋。該闊值可以通過(guò)參數(shù)long_query_ time來(lái)設(shè)置，默認(rèn)值為10, 代表 10秒晒奕。

? ??????在默認(rèn)情況下闻书，MySQL數(shù)據(jù)庫(kù)并不啟動(dòng)慢查詢(xún)?nèi)罩荆?用戶(hù)需要手工將這個(gè)參數(shù)設(shè)為ON

? ??????這里有兩點(diǎn)需要注意。首先脑慧，設(shè)置long_query_ time這個(gè)闊值后魄眉，MySQL數(shù)據(jù)庫(kù)會(huì)記錄運(yùn)行時(shí)間超過(guò)該值的所有SQL語(yǔ)句，但運(yùn)行時(shí)間正好等于long_query_ time的情況并不會(huì)被記錄下闷袒。也就是說(shuō)坑律，在源代碼中判斷的是大于long_query_ time, 而非大于等于。其次囊骤，從MySQL5.1開(kāi)始脾歇，long_query_ time開(kāi)始以微秒記錄SQL語(yǔ)句運(yùn)行的時(shí)間，之前僅用秒為單位記錄淘捡。 而這樣可以更精確地記錄SQL的運(yùn)行時(shí)間藕各， 供DBA分析。 對(duì)DBA來(lái)說(shuō)焦除， 條SQL語(yǔ)句運(yùn)行 0.5秒和0.05秒是非常不同的激况， 前者可能已經(jīng)進(jìn)行 了表掃， 后面可能是進(jìn)行了索引膘魄。

????????另一個(gè)和慢查詢(xún)?nèi)罩居嘘P(guān)的參數(shù)是log_queries_ not_ using_ indexes, 如果運(yùn)行的SQL乌逐，沒(méi)有使用索引，同樣會(huì)記錄创葡。

? ??????MySQL 5.6.5版本開(kāi)始新增了一個(gè)參數(shù)log_ thr ottle_ queries_ not_ using_indexes, 用來(lái)表示每分鐘允許記錄到slowlog 的且未使用索引的SQL語(yǔ)句次數(shù)浙踢。 該值默認(rèn)為 o. 表示沒(méi)有限制。 在生產(chǎn)環(huán)境下灿渴， 若沒(méi)有使用索引洛波， 此類(lèi)SQL語(yǔ)句會(huì)頻繁地被記錄到slow log, 從而導(dǎo)致slow log文件的大小不斷增加， 故OBA可通過(guò)此參數(shù)進(jìn)行配置骚露。

????????DBA可以通過(guò)慢查詢(xún)?nèi)罩緛?lái)找出有問(wèn)題的SQL語(yǔ)句蹬挤， 對(duì)其進(jìn)行優(yōu)化。 然而隨著MySQL數(shù)據(jù)庫(kù)服務(wù)器運(yùn)行時(shí)間的增加棘幸， 可能會(huì)有越來(lái)越多的SQL查詢(xún)被記錄到了 慢查詢(xún)?nèi)罩疚募校?此時(shí)要分析該文件就顯得不是那么簡(jiǎn)單和直觀的 了焰扳。 而這時(shí)MySQL數(shù)據(jù)庫(kù)提供的 mysqldumpslow命令，可以很好地幫助OBA解決該 問(wèn)題。

3.2.3 查詢(xún)?nèi)罩?/b>

? ??????查詢(xún)?nèi)罩居涗浟怂袑?duì)MySQL數(shù)據(jù)庫(kù)請(qǐng)求的信息吨悍， 無(wú)論這些請(qǐng)求是否得到了正確的執(zhí)行扫茅。 默認(rèn)文件名為： 主機(jī)名.log。

3.2.4 二進(jìn)制日志

? ??????二進(jìn)制日志(binary log)記錄了對(duì)MySQL數(shù)據(jù)庫(kù)執(zhí)行更改的所有操作育瓜， 但是不包括SELECT和SHOW這類(lèi)操作葫隙， 因?yàn)檫@類(lèi)操作對(duì)數(shù)據(jù)本身并沒(méi)有修改。 然而爆雹， 若操作本身并沒(méi)有導(dǎo)致數(shù)據(jù)庫(kù)發(fā)生變化停蕉， 那么該操作可能也會(huì)寫(xiě)入二進(jìn)制日志.

? ? ? ? 如果用戶(hù)想記錄SELECT和SHOW操作愕鼓， 那只能使用查詢(xún)?nèi)罩荆?而不是二進(jìn)制日志钙态。此外， 二進(jìn)制日志還包括了執(zhí)行數(shù)據(jù)庫(kù)更改操作的時(shí)間等其他額外信息菇晃。 總的來(lái)說(shuō)册倒， 二進(jìn)制日志主要有以下幾種作用:

? ??????恢復(fù)(recovery): 某些數(shù)據(jù)的恢復(fù)需要二進(jìn)制日志， 例如磺送， 在一個(gè)數(shù)據(jù)庫(kù)全備文件恢復(fù)后驻子， 用戶(hù)可以通過(guò)二進(jìn)制日志進(jìn)行point-in-time的恢復(fù)。

????????復(fù)制(replication) : 其原理與恢復(fù)類(lèi)似估灿， 通過(guò)復(fù)制和執(zhí)行二進(jìn)制日志使一臺(tái)遠(yuǎn)程的MySQL數(shù)據(jù)庫(kù)（ 一般稱(chēng)為slave或standby)與一臺(tái)MySQL數(shù)據(jù)庫(kù)（一般稱(chēng)為master或primary)進(jìn)行實(shí)時(shí)同步崇呵。

????????審計(jì)(audit) : 用戶(hù)可以通過(guò)二進(jìn)制日志中的信息來(lái)進(jìn)行審計(jì)， 判斷是否有對(duì)數(shù)據(jù)庫(kù)進(jìn)行注入的攻擊馅袁。

? ??????通過(guò)配置參數(shù)log-bin[ =name]可以啟動(dòng)二進(jìn)制日志域慷。如果不指定name,則默認(rèn)二進(jìn)制日志文件名為主機(jī)名，后綴名為二進(jìn)制日志的序列號(hào)汗销，所在路徑為數(shù)據(jù)庫(kù)所在目錄(datadir)犹褒。

? ??????二進(jìn)制日志文件在默認(rèn)情況下并沒(méi)有啟動(dòng)，需要手動(dòng)指定參數(shù)來(lái)啟動(dòng)弛针〉铮可能有人會(huì)質(zhì)疑，開(kāi)啟這個(gè)選項(xiàng)是否會(huì)對(duì)數(shù)據(jù)庫(kù)整體性能有所影響削茁。不錯(cuò)宙枷，開(kāi)啟這個(gè)選項(xiàng)的確會(huì)影響性能，但是性能的損失十分有限茧跋。根據(jù)MySQL官方手冊(cè)中的測(cè)試表明朦拖，開(kāi)啟二進(jìn)制日志會(huì)使性能下降1%。但考慮到可以使用復(fù)制(replication)和point-in-time的恢復(fù)厌衔， 這些性能損失絕對(duì)是可以且應(yīng)該被接受的璧帝。

以下配置文件的參數(shù)影響著二進(jìn)制日志記錄的信息和行為：

1.max_binlog_size

2.binlog_ cache_ size

3.sync_ binlog

4. binlog-do-db

5. binlog-ignore-db

6.log-slave-update?

7.binlog_ format

? ??????參數(shù) max_binlog_ size指定了單個(gè)二進(jìn)制日志文件的最大值， 如果超過(guò)該值富寿， 則產(chǎn)生新的二進(jìn)制日志文件睬隶， 后綴名+1, 并記錄到.index文件锣夹。 從MySQL5.0開(kāi)始的默認(rèn)值為I073 741 824, 代表1 G C在之前版本中 max_binlog_ size默認(rèn)大小為 l.IG)。

????????當(dāng)使用事務(wù)的表存儲(chǔ)引擎（如InnoDB存儲(chǔ)引擎）時(shí)苏潜， 所有未提交(uncommitted) 的二進(jìn)制日志會(huì)被記錄到一個(gè)緩存中去银萍， 等該事務(wù)提交(committed)時(shí)直接將緩沖中的二進(jìn)制日志寫(xiě)入二進(jìn)制日志文件， 而該緩沖的大小由binlog_cache_ size決定恤左， 默認(rèn)大小為32K贴唇。 此外，binlog_cache_ size是基于會(huì)話(huà)(session)的飞袋， 也就是說(shuō)戳气， 當(dāng)一個(gè)線程開(kāi)始一個(gè)事務(wù)時(shí)，MySQL會(huì)自動(dòng)分配一個(gè)大小為binlog_cache_ size的緩存巧鸭， 因此該值的設(shè)置需要相當(dāng)小心瓶您， 不能設(shè)置過(guò)大。 當(dāng)一個(gè)事務(wù)的記錄大于設(shè)定的binlog_cache_ size 時(shí)纲仍，MySQL會(huì)把緩沖中的日志寫(xiě)入一個(gè)臨時(shí)文件中呀袱， 因此該值又不能設(shè)得太小。 通過(guò)SHOW GLOBAL STATUS命令查看binlog_cache_ use郑叠、binlog_cache_ disk_ use的狀態(tài)夜赵， 可以判斷當(dāng)前binlog_ cache_ size的設(shè)置是否合適。 Binlog_ cache_ use記錄了使用緩沖寫(xiě)二 進(jìn)制日志的次數(shù)乡革，binlog_cache_ disk_ use記錄了使用臨時(shí)文件寫(xiě)二進(jìn)制日志的次數(shù)寇僧。

? ??????在默認(rèn)情況下，二進(jìn)制日志并不是在每次寫(xiě)的時(shí)候同步到磁盤(pán)（用戶(hù)可以理解為緩沖寫(xiě)）署拟。因此婉宰，當(dāng)數(shù)據(jù)庫(kù)所在操作系統(tǒng)發(fā)生右機(jī)時(shí)，可能會(huì)有最后一部分?jǐn)?shù)據(jù)沒(méi)有寫(xiě)入二進(jìn)制日志文件中推穷，這會(huì)給恢復(fù)和復(fù)制帶來(lái)問(wèn)題心包。參數(shù)sync_binlog= [NJ表示每寫(xiě)緩沖多少次就同步到磁盤(pán)。如果將N設(shè)為l, 即sync_binlog= l表示采用同步寫(xiě)磁盤(pán)的方式來(lái)寫(xiě)二進(jìn)制日志馒铃，這時(shí)寫(xiě)操作不使用操作系統(tǒng)的緩沖來(lái)寫(xiě)二進(jìn)制日志蟹腾。sync_bin log的默認(rèn)值為o, 如果使用InnoDB存儲(chǔ)引擎進(jìn)行復(fù)制，并且想得到最大的高可用性区宇，建議將該值設(shè)為ON 娃殖。不過(guò)該值為ON 時(shí)，確實(shí)會(huì)對(duì)數(shù)據(jù)庫(kù)的IO 系統(tǒng)帶來(lái)一定的影響议谷。

????????但是炉爆，即使將sync_bin log設(shè)為l, 還是會(huì)有一種情況導(dǎo)致問(wèn)題的發(fā)生。當(dāng)使用InnoDB存儲(chǔ)引擎時(shí)，在一個(gè)事務(wù)發(fā)出COMMIT動(dòng)作之前芬首，由千sync_binlog為I, 因此會(huì)將二進(jìn)制日志立即寫(xiě)入磁盤(pán)赴捞。如果這時(shí)已經(jīng)寫(xiě)入了二進(jìn)制日志，但是提交還沒(méi)有發(fā)生郁稍，并且此時(shí)發(fā)生了宅機(jī)赦政，那么在MySQL 數(shù)據(jù)庫(kù)下次啟動(dòng)時(shí)，由于COMMIT 操作并沒(méi)有發(fā)生耀怜，這個(gè)事務(wù)會(huì)被回滾掉恢着。但是二進(jìn)制日志已經(jīng)記錄了該事務(wù)信息，不能被回滾财破。這個(gè)問(wèn)題可以通過(guò)將參數(shù)innodb_ support_xa設(shè)為1來(lái)解決掰派，雖然innodb_support_ xa與XA事務(wù)有關(guān)，但它同時(shí)也確保了二進(jìn)制日志和InnoDB存儲(chǔ)引擎數(shù)據(jù)文件的同步狈究。

????????參數(shù)binlog-do-db 和binlog-ignore-db表示需要寫(xiě)入或忽略寫(xiě)入哪些庫(kù)的日志碗淌。默認(rèn)為空盏求，表示需要同步所有庫(kù)的日志到二進(jìn)制日志抖锥。

????????如果當(dāng)前數(shù)據(jù)庫(kù)是復(fù)制中的slave角色，則它不會(huì)將從master取得并執(zhí)行的二進(jìn)制日志寫(xiě)入自己的二進(jìn)制日志文件中去碎罚。如果需要寫(xiě)入磅废，要設(shè)覽log-slave-update 。如果需要搭建master=>slave=>slave架構(gòu)的復(fù)制荆烈，則必須設(shè)置該參數(shù)拯勉。

????????binlog_ format參數(shù)十分重要，它影響了記錄二進(jìn)制日志的格式憔购。在MySQL 5.1版本之前宫峦，沒(méi)有這個(gè)參數(shù)。所有二進(jìn)制文件的格式都是基于SQL語(yǔ)句(statement)級(jí)別的玫鸟，因此基于這個(gè)格式的二進(jìn)制日志文件的復(fù)制(Replication)和Oracle的邏輯Standby 有點(diǎn)相似导绷。同時(shí)， 對(duì)于復(fù)制是有一定要求的屎飘。如在主服務(wù)器運(yùn)行rand妥曲、uuid等函數(shù)，又或者使用觸發(fā)器等操作钦购，這些都可能會(huì)導(dǎo)致主從服務(wù)器上表中數(shù)據(jù)的不一致(not sync)檐盟。另一個(gè)影響是， 會(huì)發(fā)現(xiàn)lnnoDB存儲(chǔ)引擎的默認(rèn)事務(wù)隔離級(jí)別是REPEATABLE READ 押桃。這其實(shí)也是因?yàn)槎M(jìn)制日志文件格式的關(guān)系葵萎，如果使用READ COMMITTED的事務(wù)隔離級(jí)別（大多數(shù)數(shù)據(jù)庫(kù)，如Oracle, Microsoft SQL Server 數(shù)據(jù)庫(kù)的默認(rèn)隔離級(jí)別），會(huì)出現(xiàn)類(lèi)似丟失更新的現(xiàn)象羡忘， 從而出現(xiàn)主從數(shù)據(jù)庫(kù)上的數(shù)據(jù)不一致锡足。

????????MySQL 5.1開(kāi)始引入了binlog_format參數(shù)， 該參數(shù)可設(shè)的值有STATEMENT壳坪、ROW和MIXED舶得。

(I) STATEMENT格式和之前的MySQL版本一樣，二進(jìn)制日志文件記錄的是日志的邏輯SQL語(yǔ)句爽蝴。

(2)在ROW格式下沐批， 二進(jìn)制日志記錄的不再是簡(jiǎn)單的SQL語(yǔ)句了， 而是記錄表的行更改情況蝎亚【藕ⅲ基于ROW格式的復(fù)制類(lèi)似于Or acle 的物理Standby (當(dāng)然， 還是有些區(qū)別）发框。同時(shí)躺彬， 對(duì)上述提及的Statement格式下復(fù)制的問(wèn)題予以解決。從MySQL 5.1版本開(kāi)始梅惯， 如果設(shè)置了binlog_ format為ROW , 可以將InnoDB的事務(wù)隔離基本設(shè)為READCOMMITTED, 以獲得更好的并發(fā)性宪拥。

(3)在MIXED格式下， MySQL默認(rèn)采用STATEMENT格式進(jìn)行二進(jìn)制日志文件的記錄铣减， 但是在一些情況下會(huì)使用ROW格式她君， 可能的情況有：

1) 表的存儲(chǔ)引擎為NOB,這時(shí)對(duì)表的DML操作都會(huì)以ROW格式記錄。

2)使用了UUIDO葫哗、USERO缔刹、C URRENT_USERQ、FOUND_ROWSQ劣针、ROW_COUNTQ等不確定函數(shù)校镐。

3)使用了INSERT DELAY語(yǔ)句。

4)使用了用戶(hù)定義函數(shù)(UDF)捺典。

5)使用了臨時(shí)表(t empor ary table) 鸟廓。

此外， binlog_format參數(shù)還有對(duì)于存儲(chǔ)引擎的限制辣苏， 如表3-1所示肝箱。

3.3 套接字文件

? ??????前面提到過(guò)，在UNIX系統(tǒng)下本地連接MySQL可以采用UNIX域套接字方式稀蟋，這種方式需要一個(gè)套接字(socket)文件煌张。套接字文件可由參數(shù)socket控制。一般在/tmp目錄下退客，名為mysql.sock骏融。

3.4 pid文件

????????當(dāng)MySQL實(shí)例啟動(dòng)時(shí)链嘀，會(huì)將自己的進(jìn)程ID寫(xiě)人一個(gè)文件中一—該文件即為pid文件。該文件可由參數(shù)pid_file控制档玻，默認(rèn)位于數(shù)據(jù)庫(kù)目錄下怀泊，文件名為主機(jī)名.pid。

3.5 表結(jié)構(gòu)定義文件

????????因?yàn)镸ySQL插件式存儲(chǔ)引擎的體系結(jié)構(gòu)的關(guān)系误趴， MySQL數(shù)據(jù)的存儲(chǔ)是根據(jù)表進(jìn)行的霹琼， 每個(gè)表都會(huì)有與之對(duì)應(yīng)的文件。 但不論表采用何種存儲(chǔ)引擎凉当， MySQL都有一個(gè)以frm為后綴名的文件枣申， 這個(gè)文件記錄了該表的表結(jié)構(gòu)定義。

????????frm還用來(lái)存放視圖的定義看杭， 如用戶(hù)創(chuàng)建了一個(gè)v_a視圖忠藤， 那么對(duì)應(yīng)地會(huì)產(chǎn)生一 個(gè)v_a.frm文件， 用來(lái)記錄視圖的定義楼雹， 該文件是文本文件模孩， 可以直接使用cat命令進(jìn)行查看

3.6 InnoDB存儲(chǔ)引擎文件

????????之前介紹的文件都是MySQL數(shù)據(jù)庫(kù)本身的文件， 和存儲(chǔ)引擎無(wú)關(guān)贮缅。 除了這些文件外榨咐， 每個(gè)表存儲(chǔ)引擎還有其自己獨(dú)有的文件。 本節(jié)將具體介紹與InnoDB存儲(chǔ)引擎密切相關(guān)的文件携悯， 這些文件包括重做日志文件祭芦、 表空間文件筷笨。

3.6.1 表空間文件

? ??????lnnoDB采用將存儲(chǔ)的數(shù)據(jù)按表空間(tablespace)進(jìn)行存放的設(shè)計(jì)憔鬼。 在默認(rèn)配置下會(huì)有 一個(gè)初始大小為10MB, 名為ibdatal的文件 。 該文件就是默認(rèn)的表空間文件 (tablespace file), 用戶(hù)可以通過(guò)參數(shù)ionodb_data_ file _path對(duì)其進(jìn)行設(shè)置胃夏， 格式如下：

? ??????innodb_data_file_path=data/ile_specl [; datafile_spec2] ...

用戶(hù)可以通過(guò)多個(gè)文件組成一個(gè)表空間轴或， 同時(shí)制定文件的 屬性， 如：

[mysqld)

innodb_data_file_path = /db/ibdatal: 2000M; /dr2/db/ ibdata2: 2000M: autoextend

? ??????這里將/db/ibdata l和/dr2/db/ibdata2 兩個(gè)文件用來(lái)組成表空間仰禀。若這兩個(gè)文件位于不同的磁盤(pán)上照雁， 磁盤(pán)的負(fù)載可能被平均， 因此可以提高數(shù)據(jù)庫(kù)的整體性能答恶。 同時(shí)饺蚊， 兩個(gè) 文件的文件名后都跟了屬性， 表示文件 idbdatal的大小為2000MB, 文件 ibdata2的大小為2000MB, 如果用完了這2000MB, 該文件可以自動(dòng)增長(zhǎng)(autoextend)悬嗓。

????????設(shè)置innodb_data_ file _path參數(shù)后污呼， 所有基于InnoDB存儲(chǔ)引擎 的表的數(shù)據(jù)都會(huì)記錄到該共享表空間中。 若設(shè)置了參數(shù)innodb_ file _per_ table , 則用戶(hù)可以將每個(gè)基于 InnoDB存儲(chǔ)引擎的表產(chǎn)生一個(gè)獨(dú)立表空間包竹。 獨(dú)立表空間的命名規(guī)則為： 表名.ibd燕酷。通過(guò)這樣的方式籍凝， 用戶(hù)不用將所有數(shù)據(jù)都存放于默認(rèn)的表空間中。

3.6.2 重做日志文件

? ??????在默認(rèn)情況下苗缩，在InnoDB存儲(chǔ)引擎的數(shù)據(jù)目錄下會(huì)有兩個(gè)名為ib_ logfileO和ib_ logfilel的文件饵蒂。在MySQL官方手冊(cè)中將其稱(chēng)為InnoDB存儲(chǔ)引擎的日志文件，不過(guò)更準(zhǔn)確的定義應(yīng)該是重做日志文件(redolog file)酱讶。為什么強(qiáng)調(diào)是重做日志文件呢退盯？因?yàn)?重做日志文件對(duì)于InnoDB存儲(chǔ)引擎至關(guān)重要，它們記錄了對(duì)于InnoDB存儲(chǔ)引擎的事務(wù)日志泻肯。

????????當(dāng)實(shí)例或介質(zhì)失敗 (media failure) 時(shí)得问， 重做日志文件就能派上用場(chǎng)。 例如软免， 數(shù)據(jù)庫(kù) 由于所在主機(jī)掉電導(dǎo)致實(shí)例失敗宫纬， InnoDB 存儲(chǔ)引擎會(huì)使用重做日志恢復(fù)到掉電前的時(shí)刻， 以此來(lái)保證數(shù)據(jù)的完整性膏萧。

????????每個(gè) InnoDB 存儲(chǔ)引擎至少有 1 個(gè)重做日志文件組 (group), 每個(gè)文件組下至少有 2 個(gè)重做日志文件漓骚， 如默認(rèn)的 ib_ logfileO和 ib_ logfile 1。為了得到更高的可靠性榛泛， 用戶(hù) 可以設(shè)置多個(gè)的鏡像日志組 (mirrored log groups), 將不同的文件組放在不同的磁盤(pán)上蝌蹂， 以此提高重做日志的高可用性。 在日志組中每個(gè)重做日志文件的大小一致曹锨， 并以循環(huán)寫(xiě)人的方式運(yùn)行孤个。InnoDB存儲(chǔ)引擎先寫(xiě)重做日志文件I,當(dāng)達(dá)到文件的最后時(shí)，會(huì)切換至重做日志文件2, 再當(dāng)重做日志文件2也被寫(xiě)滿(mǎn)時(shí)沛简，會(huì)再切換到重做日志文件1中齐鲤。

? ??????下列參數(shù)影響著重做日志文件的屬性：

innodb_log_file_size

l innodb _log_ files_ in _group?

l innodb _mirrored_ log_groups?

l innodb _ log_group _home_ dir

? ??????參數(shù) innodb_log_file_size 指定每個(gè)重做日志文件的大小。在 lnnoDB1.2.x 版本之前椒楣， 重做日志文件總的大小不得大于等于 4GB, 而 1.2.x 版本將該限制擴(kuò)大為了 512GB给郊。

????????參數(shù) innodb_log_files _in _group 指定了日志文件組中重做日志文件的數(shù)景，默認(rèn)為2捧灰。參數(shù) innodb_ mirrored _log_groups 指定了日志鏡像文件組的數(shù)量淆九，默認(rèn)為1, 表示只有一個(gè)日志文件組，沒(méi)有鏡像毛俏。若磁盤(pán)本身已經(jīng)做了高可用的方案炭庙，如磁盤(pán)陣列，那么可以不開(kāi)啟重做日志鏡像的功能煌寇。最后焕蹄，參數(shù)innodb_log_group _home_ dir 指定了日志文件組所在路徑，默認(rèn)為.I'表示在 MySQL 數(shù)據(jù)庫(kù)的數(shù)據(jù)目錄下唧席。

? ??????重做日志文件的大小設(shè)置對(duì)于 InnoDB 存儲(chǔ)引擎的性能有著非常大的影響擦盾。一方面做日志文件不能設(shè)姓得太大嘲驾，如果設(shè)置得很大，在恢復(fù)時(shí)可能需要很的時(shí)間迹卢；一方面又不能設(shè)置得太小了辽故， 否則可能導(dǎo)致一個(gè)事務(wù)的日志需要多次切換重做日志文件。此外腐碱， 重做日志文件太小會(huì)導(dǎo)致頻繁地發(fā)生async checkpoint, 導(dǎo)致性能的抖動(dòng)誊垢。

? ??????在InnoDB存儲(chǔ)引擎中，對(duì)于各種不同的操作有著不同的重做日志格式症见。到InnoDB1.2.X版本為止喂走，總共定義51種重做日志類(lèi)型。 雖然各種重做日志的類(lèi)型不同谋作， 但是它們有著基本的格式芋肠， 表3-2顯示了重做日志條目的結(jié)構(gòu)：

? ??????從表3-2可以看到重做日志條目是由4個(gè)部分組成：

1 redo_log_type占用1字節(jié)， 表示重做日志的類(lèi)型

redo_log_body

2 space表示表空間的ID, 但采用壓縮的方式遵蚜， 因此占用的空間可能小于4字節(jié)

3 page_no表示頁(yè)的偏移盈帖池， 同樣采用壓縮的方式

4 redo_log_body表示每個(gè)重做日志的數(shù)據(jù)部分， 恢復(fù)時(shí)需要調(diào)用相應(yīng)的函數(shù)進(jìn)行解析

? ??????在第2章中已經(jīng)提到吭净， 寫(xiě)入重做日志文件的操作不是直接寫(xiě)睡汹， 而是先寫(xiě)入一個(gè)重做日志緩沖(redo log buff er)中， 然后按照一定的條件順序地寫(xiě)入日志文件寂殉。圖3-3很好地詮釋了重做日志的寫(xiě)入過(guò)程囚巴。

????????從重做日志緩沖往磁盤(pán)寫(xiě)人時(shí)， 是按512個(gè)字節(jié)友扰， 也就是一個(gè)扇區(qū)的大小進(jìn)行寫(xiě)入彤叉。因?yàn)樯葏^(qū)是寫(xiě)入的最小單位， 因此可以保證寫(xiě)入必定是成功的焕檬。因此在重做日志的寫(xiě)人過(guò)程中不需要有doublewrite姆坚。

????????前面提到了從日志緩沖寫(xiě)入磁盤(pán)上的重做日志文件是按一定條件進(jìn)行的， 那這些條件有哪些呢实愚？第2章分析了主線程(master thread), 知道在主線程中每秒會(huì)將重做日志緩沖寫(xiě)人磁盤(pán)的重做日志文件中， 不論事務(wù)是否已經(jīng)提交兔辅。另一個(gè)觸發(fā)寫(xiě)磁盤(pán)的過(guò)程是由參數(shù)innodb_fl ush_ log_ at_ trx_ com mit控制腊敲， 表示在提交(commit)操作時(shí)， 處理重做日志的方式维苔。

? ??????參數(shù)innodb_flush_ log_ at_ trx_ commit的有效值有0碰辅、1、2介时。0代表當(dāng)提沒(méi)患縊啪?? 不將事務(wù)的重做日志寫(xiě)入磁盤(pán)上的日志文件没宾，而是等待主線程每秒的刷新凌彬。1和2不同的地方在于：1表示在執(zhí)行commit時(shí)將重做日志緩沖同步寫(xiě)到磁盤(pán)，即伴有fsync的調(diào)用循衰。2表示將重做日志異步寫(xiě)到磁盤(pán)铲敛，即寫(xiě)到文件系統(tǒng)的緩存中。因此不能完全保證在執(zhí)行commit時(shí)肯定會(huì)寫(xiě)入重做日志文件会钝，只是有這個(gè)動(dòng)作發(fā)生伐蒋。

????????因此為了保證事務(wù)的ACID中的持久性，必須將innodb_flush_log_at_trx_commit設(shè)置為1,也就是每當(dāng)有事務(wù)提交時(shí)迁酸，就必須確保事務(wù)都已經(jīng)寫(xiě)入重做日志文件先鱼。那么當(dāng)數(shù)據(jù)庫(kù)因?yàn)橐馔獍l(fā)生宅機(jī)時(shí)，可以通過(guò)重做日志文件恢復(fù)奸鬓，并保證可以恢復(fù)已經(jīng)提交的事務(wù)焙畔。而將重做日志文件設(shè)置為0或2,都有可能發(fā)生恢復(fù)時(shí)部分事務(wù)的丟失。不同之處在于串远，設(shè)置為2時(shí)闹蒜，當(dāng)MySQL數(shù)據(jù)庫(kù)發(fā)生右機(jī)而操作系統(tǒng)及服務(wù)器并沒(méi)有發(fā)生者機(jī)時(shí)，由于此時(shí)未寫(xiě)人磁盤(pán)的事務(wù)日志保存在文件系統(tǒng)緩存中抑淫，當(dāng)恢復(fù)時(shí)同樣能保證數(shù)據(jù) 不丟失绷落。

3.7 小結(jié)

????????本章介紹了與MySQL數(shù)據(jù)庫(kù)相關(guān)的一些文件特碳，并了解了文件可以分為MySQL數(shù)據(jù)庫(kù)文件以及與各存儲(chǔ)引擎相關(guān)的文件瘾蛋。與MySQL數(shù)據(jù)庫(kù)有關(guān)的文件中，錯(cuò)誤文件和 二進(jìn)制日志文件非常重要姑原。當(dāng)MySQL數(shù)據(jù)庫(kù)發(fā)生任何錯(cuò)誤時(shí)催式，OBA首先就應(yīng)該去查看錯(cuò)誤文件函喉，從文件提示的內(nèi)容中找出問(wèn)題的所在。當(dāng)然荣月，錯(cuò)誤文件不僅記錄了錯(cuò)誤的內(nèi)容管呵，也記錄了警告的信息，通過(guò)一些警告也有助于 OBA對(duì)于數(shù)據(jù)庫(kù)和存儲(chǔ)引擎進(jìn)行優(yōu)化哺窄。

????????二進(jìn)制日志的作用非常關(guān)鍵捐下，可以用來(lái)進(jìn) 行point in time的恢復(fù)以及復(fù)制(replication)環(huán)境的搭建。因此萌业，建議在任何時(shí)候時(shí)都啟用二進(jìn)制日志的記錄坷襟。 從MySQL 5.1開(kāi)始，二進(jìn)制日志支持STATEMENT生年、ROW婴程、MIX三種格式，這樣可以更好地保證從數(shù)據(jù)庫(kù)與主數(shù)據(jù)庫(kù)之間數(shù)據(jù)的一致性抱婉。當(dāng)然 OBA應(yīng)該十分清楚這三種不同 格式之間的差異档叔。

????????本章的最后介紹了和InnoDB存儲(chǔ)引擎相關(guān)的文件桌粉，包括表空間文件和重做日志文件。表空間文件是用來(lái)管理InnoDB存儲(chǔ)引擎的存儲(chǔ)衙四，分為共享表空間和獨(dú)立表空間铃肯。重做日志非常的重要，用來(lái)記錄InnoDB存儲(chǔ)引擎的事務(wù)日志届搁，也因?yàn)橹刈鋈罩镜拇嬖谠笛Γ攀沟肐nnoDB存儲(chǔ)引擎可以提供可靠的事務(wù)。