參考黑馬架構(gòu)課程
一 存儲引擎體系
1.1 MySQL體系架構(gòu)
上圖描述
Connection Pool : 連接池組件
Management Services & Utilities : 管理服務(wù)和工具組件
SQL Interface : SQL接口組件
Parser : 查詢分析器組件
Optimizer : 優(yōu)化器組件
Caches & Buffers : 緩沖池組件
Pluggable Storage Engines : 存儲引擎
File System : 文件系統(tǒng)
1. 連接層
最上層是一些客戶端和鏈接服務(wù)，包含本地sock 通信和大多數(shù)基于客戶端/服務(wù)端工具實現(xiàn)的類似于TCP/IP
的通信。主要完成一些類似于連接處理关炼、授權(quán)認(rèn)證苞笨、及相關(guān)的安全方案。在該層上引入了線程池的概念，為
通過認(rèn)證安全接入的客戶端提供線程准颓。同樣在該層上可以實現(xiàn)基于SSL的安全鏈接梯刚。服務(wù)器也會為安全接入的
每個客戶端驗證它所具有的操作權(quán)限凉馆。
2. 服務(wù)層
第二層架構(gòu)主要完成大多數(shù)的核心服務(wù)功能，如SQL接口亡资，并完成緩存的查詢澜共，SQL的分析和優(yōu)化，部分內(nèi)置
函數(shù)的執(zhí)行锥腻。所有跨存儲引擎的功能也在這一層實現(xiàn)嗦董，如 過程、函數(shù)等。在該層，服務(wù)器會解析查詢并創(chuàng)建
相應(yīng)的內(nèi)部解析樹叛薯，并對其完成相應(yīng)的優(yōu)化如確定表的查詢的順序偷霉，是否利用索引等，最后生成相應(yīng)的執(zhí)行
操作荸实。如果是select語句，服務(wù)器還會查詢內(nèi)部的緩存，如果緩存空間足夠大来惧，這樣在解決大量讀操作的環(huán)
境中能夠很好的提升系統(tǒng)的性能。
3. 引擎層
存儲引擎層演顾， 存儲引擎真正的負責(zé)了MySQL中數(shù)據(jù)的存儲和提取供搀，服務(wù)器通過API和存儲引擎進行通信。不
同的存儲引擎具有不同的功能钠至，這樣我們可以根據(jù)自己的需要葛虐，來選取合適的存儲引擎。
4. 存儲層
數(shù)據(jù)存儲層棉钧， 主要是將數(shù)據(jù)存儲在文件系統(tǒng)之上屿脐，并完成與存儲引擎的交互。
和其他數(shù)據(jù)庫相比，MySQL存儲引擎是插件式的存儲引擎架構(gòu)的诵。將 查詢處理和其他的系統(tǒng)任務(wù)以及數(shù)據(jù)的存儲提取分離万栅。這種架構(gòu)可 以根據(jù)業(yè)務(wù)的需求和實際需要選擇合適的存儲引擎。
1.2 存儲引擎介紹
1. 概述
針對不同的存儲需求可以選擇最優(yōu)的存儲引擎西疤。存儲引擎就是存 儲數(shù)據(jù)烦粒，建立索引，更新查詢數(shù)據(jù)等等技術(shù)的實現(xiàn)方式 代赁。存儲引 擎是基于表的扰她，而不是基于庫的。所以存儲引擎也可被稱為表類 型管跺。
2. 查看MySQL存儲引擎
3. MySQL常見兩種引擎
MySQL默認(rèn)支持InnoDB
二 InnoDB深入刨析
2.1 InnoDB體系結(jié)構(gòu)
1. 緩沖池
介紹
InnoDB存儲引擎基于磁盤文件存儲义黎，訪問物理硬盤和在內(nèi)存中進行訪問，速度相差很大豁跑，為了盡可能
彌補這兩者之間的I/O效率的差值廉涕，就需要把經(jīng)常使用的數(shù)據(jù)加載到緩沖池中，避免每次訪問都進行磁
盤I/O艇拍。
在InnoDB的緩沖池中不僅緩存了索引頁和數(shù)據(jù)頁狐蜕，還包含了undo頁、插入緩存卸夕、自適應(yīng)哈希索引以及
InnoDB的鎖信息等等层释。
讀取
在數(shù)據(jù)庫中進行讀取頁的操作時， 首先將磁盤中讀取到的頁數(shù)據(jù)存放在緩沖池中快集， 下一次再讀相同的
頁時贡羔， 首先判斷緩沖池中是否存在，如果緩沖池被命中个初，則直接讀取數(shù)據(jù)乖寒， 如果沒有，則讀取磁盤中
的頁數(shù)據(jù)院溺。
更新
而對于數(shù)據(jù)庫中頁的修改操作楣嘁，則首先修改在緩沖池中的頁，然后再以一定的頻率刷新到磁盤上珍逸，從而
保證緩沖池中的數(shù)據(jù)與磁盤中的數(shù)據(jù)一致逐虚。頁從緩沖池刷新回磁盤的操作并不是在每次頁發(fā)生更新時，
都需要觸發(fā)谆膳，出于整體的性能考慮叭爱，而是通過checkpoint機制刷新回磁盤。
參數(shù)配置
在專用服務(wù)器上漱病，通常將多達80％的物理內(nèi)存分配給緩沖池涤伐。參數(shù)設(shè)置：
show variables like 'innodb_buffer_pool_size';
在InnoDB引擎中馒胆，允許有多個緩沖池實例，根據(jù)頁的哈希值分配到不同的緩沖池實例中凝果，從而減少數(shù)
據(jù)庫內(nèi)部的資源競爭， 提升并發(fā)處理能力睦尽。 參數(shù)配置：
vi /etc/my.conf
innodb_buffer_pool_size=268435456
2. 后臺線程
Master Thread
主要負責(zé)將緩沖池中的數(shù)據(jù)異步刷新到磁盤中, 保持?jǐn)?shù)據(jù)的一致性器净， 還包括臟頁的刷新、合并插入緩
存当凡、undo頁的回收 山害。
IO Thread
在InnoDB存儲引擎中大量使用了AIO來處理IO請求, 這樣可以極大地提高數(shù)據(jù)庫的性能，而IO
Thread主要負責(zé)這些IO請求的回調(diào)沿量。
Purge Thread
主要用于回收事務(wù)已經(jīng)提交了的undo log浪慌，在事務(wù)提交之后，undo log可能不用了朴则，就用它來回
收权纤。
Pager Cleaner Thread
新引入的一個用于協(xié)助 Master Thread 刷新臟頁到磁盤的線程，它可以減輕 Master Thread 的
工作壓力乌妒，減少阻塞汹想。
3. 文件
frm文件
該文件是用來保存每個表的元數(shù)據(jù)信息的， 主要包含表結(jié)構(gòu)定義 撤蚊。
系統(tǒng)表空間
系統(tǒng)表空間是InnoDB數(shù)據(jù)字典古掏，二次寫緩沖區(qū)，更改緩沖區(qū)和撤消日志的存儲區(qū) 侦啸。系統(tǒng)表空間可以具
有一個或多個數(shù)據(jù)文件槽唾， 默認(rèn)情況下會在數(shù)據(jù)存放目錄中創(chuàng)建一個名為 ibdata1 表空間數(shù)據(jù)文件。
該文件名稱可以通過參數(shù) innodb_data_file_path 指定光涂。
file_name:file_size[:autoextend[:max:max_file_size]]
獨占表空間
innodb中設(shè)置了參數(shù) innodb_file_per_table 為 1/ON庞萍，則會將存儲的數(shù)據(jù)、索引等信息單獨
存儲在一個獨占表空間顶捷，因此也會產(chǎn)生一個獨占表空間文件（ibd）
redo log
重做日志挂绰， 用于恢復(fù)提交事務(wù)修改的頁操作 ， 用來保證事務(wù)的原子性和持久性服赎。主要是解決 提交
的事務(wù)沒有執(zhí)行完成但是數(shù)據(jù)庫崩潰了葵蒂，當(dāng)數(shù)據(jù)庫恢復(fù)之后，可以完整的恢復(fù)數(shù)據(jù)重虑。在執(zhí)行操作時践付，
InnoDB存儲引擎會首先將重做日志信息放到這個緩沖區(qū) redo log buffer,然后按照不同的策略和
頻率將buffer中的數(shù)據(jù)刷新到重做日志中。
redo log在磁盤中保存的名稱為 ib_logfile0缺厉，ib_logfile1永高。
bin log
二進制日志隧土，其中記錄表結(jié)構(gòu)中的數(shù)據(jù)變更，包含DDL與DML命爬。
其他
錯誤日志曹傀、查詢?nèi)罩尽⒙樵內(nèi)罩镜取?/p>
2.2 InnoDB邏輯存儲結(jié)構(gòu)
1. 表空間
表空間是InnoDB存儲引擎邏輯結(jié)構(gòu)的最高層饲宛， 大部分?jǐn)?shù)據(jù)都存在于共享表空間ibdata1中皆愉。如果用
戶啟用了參數(shù) innodb_file_per_table ，則每張表都會有一個表空間（xxx.ibd）,里面存放表
中的數(shù)據(jù)艇抠、索引和插入緩存Bitmap頁幕庐。其他的數(shù)據(jù)如undo log、插入緩存索引頁家淤、系統(tǒng)事務(wù)信息异剥、
二次寫緩存都是在共享表空間中。
2. 段
表空間是由各個段組成的絮重，常見的段有數(shù)據(jù)段冤寿、索引段、回滾段等绿鸣。InnoDB存儲引擎是基于索引組織
的疚沐，因此數(shù)據(jù)即是索引，索引即數(shù)據(jù)潮模。數(shù)據(jù)段就是B+樹的葉子節(jié)點亮蛔， 索引段即為B+樹的非葉子節(jié)點。
InnoDB中對于段的管理擎厢，都是引擎自身完成究流，不需要人為對其控制。
3. 區(qū)
區(qū)是表空間的單元結(jié)構(gòu)动遭，每個區(qū)的大小為1M芬探。 默認(rèn)情況下， InnoDB存儲引擎頁大小為16K厘惦， 即一
個區(qū)中一共有64個連續(xù)的頁偷仿。
4. 頁
頁是組成區(qū)的最小單元，頁也是InnoDB 存儲引擎磁盤管理的最小單元宵蕉，每個頁的大小默認(rèn)為 16KB酝静。
為了保證頁的連續(xù)性，InnoDB 存儲引擎每次從磁盤申請 4-5 個區(qū)羡玛。
5. 行
InnoDB 存儲引擎是面向行的（row-oriented)别智，也就是說數(shù)據(jù)是按行進行存放的，每個頁存放的行
記錄也是有硬性定義的稼稿，最多允許存放 16KB/2-200 行薄榛，即 7992 行記錄讳窟。
trx_id：每次對某條聚簇索引記錄進行改動時，都會把對應(yīng)的事務(wù)id賦值給trx_id隱藏列敞恋。
roll_pointer：每次對某條聚簇索引記錄進行改動時丽啡，都會把舊的版本寫入到undo日志中，然后這個隱藏列
就相當(dāng)于一個指針耳舅，可以通過它來找到該記錄修改前的信息碌上。
2.3 checkpoint
1. 介紹
由于日常的DML語句操作時，首先操作的是緩沖池浦徊，并沒有直接寫入到磁盤，這有可能會導(dǎo)致內(nèi)存中的
數(shù)據(jù)與磁盤中的數(shù)據(jù)產(chǎn)生不一致的情況天梧，而與磁盤中數(shù)據(jù)不一致的頁我們成為"臟頁"盔性。 而
checkpoint的工作，就是將內(nèi)存中的臟頁呢岗，在一定條件下刷新到磁盤冕香。
如果在從緩沖池將頁數(shù)據(jù)刷新到磁盤的過程中發(fā)生宕機，那么數(shù)據(jù)就無法恢復(fù)了后豫；為了避免這種情況的
發(fā)生悉尾，采用了Write Ahead Log(WAL)策略，即當(dāng)事務(wù)提交時挫酿，先寫重做日志(redo log)构眯，再修改
緩沖池數(shù)據(jù)頁，最后通過Checkpoint刷新到磁盤（事務(wù)提交會觸發(fā)checkpoint）早龟。這樣正在執(zhí)行的
事務(wù)惫霸，因為存在日志都可以被恢復(fù)，沒有日志的事務(wù)還沒有執(zhí)行也不會丟失數(shù)據(jù)葱弟。
2. 作用
A. 縮短數(shù)據(jù)恢復(fù)時間
當(dāng)數(shù)據(jù)庫發(fā)生宕機時壹店，數(shù)據(jù)庫不用重做所有的日志，因為Checkpoint之前的頁都已經(jīng)刷新會磁盤了芝加，
故數(shù)據(jù)庫只需要重做Checkpoint之后的日志就好硅卢，這樣就大大縮短了恢復(fù)時間。
B. 緩沖池不夠用時藏杖，需要先將臟頁數(shù)據(jù)刷新到磁盤中将塑；
當(dāng)緩沖池不夠用時, 根據(jù)LRU算法溢出最近最少使用的頁, 如果此頁是臟頁,則強制執(zhí)行
Checkpoint, 刷新臟頁到磁盤。
C. 重做日志不可用時制市，刷新臟頁到磁盤抬旺；
redo log大小是固定的, 當(dāng)前的InnoDB引擎中， 重做日志的設(shè)計都是循環(huán)使用的祥楣，并不是無限增
大的开财。重做日志可以被重用的部分是已經(jīng)不再需要的汉柒， 數(shù)據(jù)庫發(fā)生宕機也不需要這部分的重做日志，
因此可以被覆蓋使用责鳍， 如果此時重做日志還需要使用碾褂，那么必須強制執(zhí)行Checkpoint，將緩沖池中
的頁至少刷新磁盤, checkpoint移動到當(dāng)前重做日志的位置历葛。
write pos表示日志當(dāng)前記錄的位置正塌，當(dāng)ib_logfile_1寫滿后，會從ib_logfile_0從頭開始記
錄恤溶；check point表示將日志記錄的修改寫進磁盤乓诽，完成數(shù)據(jù)落盤，數(shù)據(jù)落盤后checkpoint會將日
志上的相關(guān)記錄擦除掉咒程，即write position ->checkpoint 之間的部分是redo log空著的部
分鸠天，用于記錄新的記錄，checkpoint->write position 之間是redo log待落盤的數(shù)據(jù)修改記
錄帐姻。當(dāng)write postion追上checkpoint時稠集，得先停下記錄，先推動checkpoint向前移動饥瓷，空出位
置記錄新的日志剥纷。
3. 分類
A. Sharp Checkpoint
Sharp Checkpoint 發(fā)生在數(shù)據(jù)庫關(guān)閉時，將所有的臟頁都刷新回磁盤呢铆，這是默認(rèn)的工作方式晦鞋，參
數(shù)：innodb_fast_shutdown=1。
B. Fuzzy Checkpoint
在InnoDB存儲引擎運行時刺洒，使用Fuzzy Checkpoint進行頁刷新鳖宾，只刷新一部分臟頁。
2.4 InnoDB關(guān)鍵特性
1. 插入緩存
主鍵是行唯一的標(biāo)識符逆航，在應(yīng)用程序中行記錄的插入順序一般是按照主鍵遞增的順序進行插入的鼎文。因
此，插入聚集索引一般是順序的因俐，不需要磁盤的隨機讀取拇惋。因此，在這樣的情況下抹剩，插入操作一般很快
就能完成撑帖。
但是，不可能每張表上只有一個聚集索引澳眷，在更多的情況下胡嘿，一張表上有多個非聚集的輔助索引
（secondary index）。比如钳踊，我們還需要按照name這個字段進行查找衷敌，并且name這個字段不是唯
一的, 這樣的情況下產(chǎn)生了一個非聚集的并且不是唯一的索引勿侯。在進行插入操作時，數(shù)據(jù)頁的存放還是
按主鍵id的執(zhí)行順序存放缴罗，但是對于非聚集索引助琐，葉子節(jié)點的插入不再是順序的了。這時就需要離散地
訪問非聚集索引頁面氓，插入性能在這里變低了兵钮。然而這并不是這個name字段上索引的錯誤，因為B+樹的
特性決定了非聚集索引插入的離散性舌界。
InnoDB存儲引擎開創(chuàng)性地設(shè)計了插入緩沖掘譬，對于非聚集索引的插入或更新操作，不是每一次直接插入
索引頁中呻拌，而是先判斷插入的非聚集索引頁是否在緩沖池中屁药。如果在，則直接插入柏锄；如果不在，則先放
入一個插入緩沖區(qū)中复亏，好似欺騙數(shù)據(jù)庫這個非聚集的索引已經(jīng)插到葉子節(jié)點了趾娃，然后再以一定的頻率執(zhí)
行插入緩沖和非聚集索引葉子節(jié)點的合并操作，這時通常能將多個插入合并到一個操作中（因為在一個
索引頁中）缔御，這就大大提高了對非聚集索引執(zhí)行插入和修改操作的性能抬闷。
2. 兩次寫
當(dāng)數(shù)據(jù)庫寫物理頁時，如果宕機了耕突，那么可能會導(dǎo)致物理頁的一致性被破壞笤成。
可能有人會說，重做日志不是可以恢復(fù)物理頁嗎眷茁？實際上是的炕泳，但是要求是在物理頁一致的情況下。
也就是說上祈，如果物理頁完全是未寫之前的狀態(tài)培遵，則可以用重做日志恢復(fù)。如果物理頁已經(jīng)完全寫完了登刺，
那么也可以用重做日志恢復(fù)籽腕。但是如果物理頁前面2K寫了新的數(shù)據(jù)，但是后面2K還是舊的數(shù)據(jù)纸俭，則種
情況下就無法使用重做日志恢復(fù)了皇耗。
這里的兩次寫就是保證了物理頁的一致性，使得即使宕機揍很，也可以用重做日志恢復(fù)郎楼。
在寫物理頁時万伤，并不是直接寫到真正的物理頁上去，而是先寫到一個臨時頁上去箭启，臨時頁寫完后壕翩，再寫
物理頁。這樣一來：
A. 如果寫臨時頁時宕機了傅寡，物理頁還是完全未寫之前的狀態(tài)放妈，可以用重做日志恢復(fù)
B. 如果寫物理頁時宕機了，則可以使用臨時頁來恢復(fù)物理頁
每次寫物理頁時荐操，先寫到double write buffer中芜抒，然后從double write buffer寫到double
write上去。最后再從double write buffer寫到物理頁上去托启。
3. 自適應(yīng)hash索引
在InnoDB中默認(rèn)支持的索引結(jié)構(gòu)為 B+ 樹宅倒，B+ 樹索引可以使用到范圍查找，同時是按照順序的方式
對數(shù)據(jù)進行存儲屯耸，因此很容易對數(shù)據(jù)進行排序操作拐迁，在聯(lián)合索引中也可以利用部分索引鍵進行查詢 。
而對于Hash索引則只能滿足 =疗绣，<>,in查詢线召，不能使用范圍查詢， 而且數(shù)據(jù)的存儲是沒有順序的多矮。
MySQL 默認(rèn)使用 B+ 樹作為索引缓淹，因為 B+ 樹有著 Hash 索引沒有的優(yōu)點，那么為什么還需要自
適應(yīng) Hash 索引呢塔逃？
這是因為B+樹的查找次數(shù)讯壶，取決于B+樹的高度，在生產(chǎn)環(huán)境中湾盗，B+樹的高度一般為3-4層伏蚊，故需要3-4
次查詢。而 Hash 索引在進行數(shù)據(jù)檢索的時候效率非常高淹仑，通常只需要 O(1) 的復(fù)雜度丙挽，也就是一
次就可以完成數(shù)據(jù)的檢索。雖然 Hash 索引的使用場景有很多限制匀借，但是優(yōu)點也很明顯颜阐。InnoDB存儲
引擎會監(jiān)控對表上各索引頁的查詢，如果觀察到hash索引可以提升速度吓肋，則建立hash索引凳怨，稱之為自
適應(yīng)hash索引（Adaptive Hash Index，AHI）。
注意肤舞，這里的自適應(yīng)指的是不需要人工來指定紫新，系統(tǒng)會根據(jù)情況自動完成。
什么情況下才會使用自適應(yīng) Hash 索引呢李剖？如果某個數(shù)據(jù)經(jīng)常被訪問芒率，當(dāng)滿足一定條件的時候，就會
將這個數(shù)據(jù)頁的地址存放到 Hash 表中篙顺。這樣下次查詢的時候偶芍，就可以直接找到這個頁面的所在位
置。值得注意的是德玫，hash索引只能用于= 匪蟀，in的查詢，對于其他的查詢類型宰僧，如范圍匹配等是不能使
用hash索引的材彪。而且自適應(yīng) Hash 索引只保存熱數(shù)據(jù)（經(jīng)常被使用到的數(shù)據(jù)），并非全表數(shù)據(jù)琴儿。因此
數(shù)據(jù)量并不會很大段化，因此自適應(yīng) Hash 也是存放到緩沖池中，這樣也進一步提升了查找效率造成。
4. 異步IO
為了提高磁盤的操作性能穗泵，在InnoDB存儲引擎中使用異步非阻塞AIO的方式來操作磁盤。
與AIO對應(yīng)的是Sync IO谜疤，如果是同步IO操作，則每進行一次IO操作现诀，需要等待此次操作結(jié)束后才可
以進行接下來的操作夷磕。但是如果用戶發(fā)出的是一條索引掃描的查詢，那么這條SQL查詢語句可能需要掃
描多個索引頁仔沿，也就是需要進行多次的IO操作坐桩。每掃描一個頁并等待其完成之后，再進行下一次掃描封锉，
這是沒有必要的绵跷。
用戶可以在發(fā)出一個IO請求后立即再發(fā)出另一個IO請求，當(dāng)全部的IO請求發(fā)送完畢后成福，等待所有的IO
操作完成碾局，這就是AIO。
5. 刷新臨接頁
InnoDB提供刷新臨近頁功能：當(dāng)刷新一臟頁時奴艾，同時檢測所在區(qū)(extent)的所有頁净当，如果有臟頁則
一并刷新，好處則是通過AIO特性合并寫IO請求，缺點則是有些頁不怎么臟也好被刷新像啼，而且頻繁的更
改那些不怎么臟的頁又很快變成臟頁俘闯，造成頻繁刷新。對于固態(tài)磁盤則考慮關(guān)閉此功能（將
innodb_flush_neighbors設(shè)置為0）忽冻。
2.5 InnoDB事務(wù)
事務(wù)可由一條簡單的SQL語句組成真朗，也可以由一組復(fù)雜的SQL語句組成。事務(wù)是訪問并更新數(shù)據(jù)庫中各
個數(shù)據(jù)項的一個程序執(zhí)行單元僧诚。在事務(wù)操作時遮婶，這組執(zhí)行單元中的SQL，要么全部成功振诬， 要么全部失
敗蹭睡。
1. 事務(wù)具有以下四個特性(ACID)
2. 隔離級別
并發(fā)事務(wù)帶來的問題：
為了解決上述提到的事務(wù)并發(fā)問題，數(shù)據(jù)庫提供一定的事務(wù)隔離機制來解決這個問題赶么。數(shù)據(jù)庫的事務(wù)隔
離越嚴(yán)格肩豁，并發(fā)副作用越小，但付出的代價也就越大辫呻，因為事務(wù)隔離實質(zhì)上就是使用事務(wù)在一定程度上
“串行化” 進行清钥，這顯然與“并發(fā)” 是矛盾的。
數(shù)據(jù)庫的隔離級別有4個放闺，由低到高依次為Read uncommitted祟昭、Read committed、Repeatable
read怖侦、Serializable篡悟，這四個級別可以逐個解決臟寫、臟讀匾寝、不可重復(fù)讀搬葬、幻讀這幾類問題。
3. 實現(xiàn)
1). redo log
redo log叫做重做日志艳悔，是用來實現(xiàn)事務(wù)的持久性急凰。該日志文件由兩部分組成：重做日志緩沖（redo
log buffer）以及重做日志文件（redo log）,前者是在內(nèi)存中，后者在磁盤中猜年。當(dāng)事務(wù)提交之后
會把所有修改信息都會存到該日志中, 用于在刷新臟頁到磁盤時,發(fā)生錯誤時, 進行數(shù)據(jù)恢復(fù)使用。
例：
執(zhí)行事務(wù)操作
start transaction;
select balance from bank where name="Tom";
-- 生成 重做日志 balance=8000
update bank set balance = balance - 2000;
-- 生成 重做日志 account=2000
update finance set account = account + 2000;
commit;
流程
mysql 為了提升性能不會把每次的修改都實時同步到磁盤乔外，而是會先存到Buffer Pool(緩沖池)里
頭床三，把這個當(dāng)作緩存來用。然后使用后臺線程將緩存池刷新到磁盤杨幼。
當(dāng)在執(zhí)行刷新時勿璃，宕機或者斷電，可能會丟失部分?jǐn)?shù)據(jù)。所以引入了redo log來記錄已成功提交事務(wù)
的修改信息补疑，并且在事務(wù)提交時會把redo log持久化到磁盤歧沪，系統(tǒng)重啟之后在讀取redo log恢復(fù)最
新數(shù)據(jù)。
簡單來說 莲组， redo log是用來恢復(fù)數(shù)據(jù)的 用于保障诊胞，已提交事務(wù)的持久化特性 ;
2). undo log
undo log 叫做回滾日志，用于記錄數(shù)據(jù)被修改前的信息锹杈。他正好跟前面所說的重做日志所記錄的相
反撵孤，重做日志記錄數(shù)據(jù)被修改后的信息。undo log主要記錄的是數(shù)據(jù)的邏輯變化竭望，為了在發(fā)生錯誤時
回滾之前的操作邪码，需要將之前的操作都記錄下來，然后在發(fā)生錯誤時才可以回滾咬清。
undo log 記錄事務(wù)修改之前版本的數(shù)據(jù)信息闭专，因此假如由于系統(tǒng)錯誤或者rollback操作而回滾的話
可以根據(jù)undo log的信息來進行回滾到?jīng)]被修改前的狀態(tài)。
三 存儲引擎應(yīng)用場景
在選擇存儲引擎時旧烧，應(yīng)該根據(jù)應(yīng)用系統(tǒng)的特點選擇合適的存儲引擎影钉。對于復(fù)雜的應(yīng)用系統(tǒng)，還可以根據(jù)
實際情況選擇多種存儲引擎進行組合掘剪。以下是幾種常用的存儲引擎的使用環(huán)境 平委。
InnoDB : 是Mysql的默認(rèn)存儲引擎，用于事務(wù)處理應(yīng)用程序夺谁，支持外鍵, 行鎖廉赔。如果應(yīng)用對事
務(wù)的完整性有比較高的要求，在并發(fā)條件下要求數(shù)據(jù)的一致性匾鸥，數(shù)據(jù)操作除了插入和查詢以外昂勉，還
包含很多的更新、刪除操作扫腺，那么InnoDB存儲引擎是比較合適的選擇。InnoDB存儲引擎除了有
效的降低由于刪除和更新導(dǎo)致的鎖定村象， 還可以確保事務(wù)的完整提交和回滾笆环，對于電商系統(tǒng)中的商
品（SPU、SKU厚者、分類躁劣、品牌）、訂單库菲、用戶等信息的存儲账忘，InnoDB是最合適的選擇。
MyISAM ： 如果應(yīng)用是以讀操作和插入操作為主，只有很少的更新和刪除操作鳖擒，并且對事務(wù)的完
整性溉浙、并發(fā)性要求不是很高，那么選擇這個存儲引擎是非常合適的蒋荚。對于電商系統(tǒng)中戳稽，系統(tǒng)的操作
日志、用戶評價期升、足跡等信息的存儲惊奇，MyISAM是合適的選擇。
