一、邏輯存儲結構

表空間(ibd文件),一個MySQL實例可以對應多個表空間，用于存儲記錄，索引等數(shù)據(jù)。

段，分為數(shù)據(jù)段、索引段、回滾段，innodb是索引組織表，數(shù)據(jù)段就是B+Tree的葉子節(jié)點，索引段為非葉子節(jié)點，段用來管理多個區(qū)。

區(qū)，表空間的單元結構，每個區(qū)的大小為1M,默認情況下，innodb存儲引擎頁大小為16K，即一個區(qū)中一共有64個連續(xù)的頁。

頁，是innodb存儲引擎磁盤管理的最小單元，每個頁的大小為16K，為了保證頁的連續(xù)性，innodb存儲引擎每次從磁盤申請4~5個區(qū)。

行，innodb存儲引擎數(shù)據(jù)是按行進行存儲的。Trx_id 最后一次事務操作的id、roll_pointer滾動指針。

innodb的內存結構，由Buffer Pool、Change Buffer和Log Buffer組成。

Buffer Pool: 緩沖池是主內存中的一個區(qū)域，里面可以緩存磁盤上經(jīng)常操作的真實數(shù)據(jù)，在執(zhí)行增刪改查操作時，先操作緩沖池中的數(shù)據(jù)(若緩沖池么有數(shù)據(jù)，則從磁盤加載并緩存)，然后再以一定頻率刷新磁盤，從而減少磁盤IO，加快處理速度。

緩沖池以page頁為單位，底層采用鏈表數(shù)據(jù)結構管理page，根據(jù)狀態(tài)，將page分為三種類型:

1、free page 即空閑page，未被使用。

2、clean page 被使用page，數(shù)據(jù)沒有被修改過。

3、dirty page 臟頁，被使用page，數(shù)據(jù)被修改過，這個page當中的數(shù)據(jù)和磁盤當中的數(shù)據(jù) 不一致。說得簡單點就是緩沖池中的數(shù)據(jù)改了，磁盤中的沒改，因為還沒刷寫到磁盤。

Change Buffer：更改緩沖區(qū)(針對于非唯一二級索引頁)，在執(zhí)行DML語句時，如果這些數(shù)據(jù)page沒有在Buffer Pool中，不會直接操作磁盤，而會將數(shù)據(jù)變更存在更改緩沖區(qū)Change Buffer中，在未來數(shù)據(jù)被讀取時。再將數(shù)據(jù)合并恢復到Buffer Pool中，再將合并后的數(shù)據(jù)刷新到磁盤中。

二級索引通常是非唯一的，并且以相對隨機的順序插入二級索引頁，同樣，刪除和更新可能會影響索引樹中不相鄰的二級索引頁。如果每一次都操作磁盤，會造成大量磁盤IO，有了Change Buffer之后，我們可以在緩沖池中進行合并處理，減少磁盤IO。

Adaptive Hash Index：自適應hash索引，用于優(yōu)化對Buffer Pool數(shù)據(jù)的查詢，InnoDB存儲引擎會監(jiān)控對表上各索引頁的查詢，如果觀察到hash索引可以提升速度，則建立hash索引，稱之為自適應hash索引。無需人工干預，系統(tǒng)根據(jù)情況自動完成。

參數(shù)：
innodb_adaptive_hash_index

mysql> show variables like '%hash_index%';
+----------------------------------+-------+
| Variable_name | Value |
+----------------------------------+-------+
| innodb_adaptive_hash_index | ON |
| innodb_adaptive_hash_index_parts | 8 |
+----------------------------------+-------+
2 rows in set (0.01 sec)

Log Buffer: 日志緩沖區(qū)，用來保存要寫入到磁盤中的log日志數(shù)據(jù)(redo log、undo log)，默認大小為16M，日志緩沖區(qū)的日志會定期刷新到磁盤中，如果需要更新，插入或刪除許多行的事務，增加日志緩沖區(qū)的大小可以節(jié)省磁盤IO。

參數(shù): innodb_log_buffer_size 緩沖區(qū)大小

innodb_flush_log_at_trx_commit 日志刷新到磁盤時機

innodb_flush_log_at_trx_commit=1 表示日志在每次事務提交時寫入并刷新到磁盤

2 表示日志在每次事務提交后寫入，并每秒刷新到磁盤一次

0 表示每秒將日志寫入并刷新到磁盤一次。

InnoDB 的磁盤結構，由系統(tǒng)表空間(ibdata1)，獨立表空間(*.ibd),通用表空間，撤銷表空間(undo tablespaces), 臨時表空間(Temporary Tablespaces), 雙寫緩沖區(qū)(Doublewrite Buffer files), 重做日志(Redo Log).

系統(tǒng)表空間(ibdata1)：系統(tǒng)表空間是更改緩沖區(qū)的存儲區(qū)域，如果表是在系統(tǒng)表空間而不是每個表文件或者通用表空間中創(chuàng)建的，它也可能包含表和索引數(shù)據(jù)。

參數(shù)為: innodb_data_file_path

獨立表空間(*.ibd): 每個表的文件表空間包含單個innodb表的數(shù)據(jù)和索引，并存儲在文件系統(tǒng)上的單個數(shù)據(jù)文件中。參數(shù): innodb_file_per_table

通用表空間: 需要通過create tablespace 語法創(chuàng)建，創(chuàng)建表時可以指定該表空間。

create tablespace xxx add datafile 'file_name' engine=engine_name

create table table_name .... tablespace xxx

撤銷表空間(undo tablespaces): MySQL實例在初始化時會自動創(chuàng)建兩個默認的undo表空間(初始大小16K，undo_001,undo_002)，用于存儲undo log 日志

臨時表空間(Temporary Tablespaces)： innodb使用會話臨時表空和全局表空間，存儲用戶創(chuàng)建的臨時表等數(shù)據(jù)。

雙寫緩沖區(qū)(Doublewrite Buffer files)： innodb引擎將數(shù)據(jù)頁從Buffer Pool刷新到磁盤前，先將數(shù)據(jù)頁寫入緩沖區(qū)文件中，便于系統(tǒng)異常時恢復數(shù)據(jù)。

重做日志(Redo Log)：是用來實現(xiàn)事務的持久性，該日志文件由兩部分組成，重做日志緩沖區(qū)(redo log buffer)以及重做日志文件(redo log)，前者是在內存中，后者在磁盤中，當事務提交之后會把修改信息都會存儲到該日志中，用于在刷新臟頁到磁盤時，發(fā)送錯誤時，進行數(shù)據(jù)恢復使用。以循環(huán)方式寫入重做日志文件，涉及兩個文件ib_logfile0,ib_logfile1。

那內存結構中的數(shù)據(jù)是如何刷新到磁盤中的? 在MySQL中有4個線程負責刷新日志到磁盤。

1、Master Thread， mysql核心后臺線程，負責調度其它線程，還負責將緩沖池中的數(shù)據(jù)異步刷新到磁盤中，保持數(shù)據(jù)的一致性，還包括臟頁的刷新，合并插入緩沖、undo頁的回收。

2、IO Thread，在innodb存儲引擎中大量使用了AIO來處理IO請求，這樣可以極大地提高數(shù) 據(jù)庫的性能，而IO Thead主要負責這些IO請求的回調。

4個讀線程 Read thread負責讀操作

4個寫線程write thread負責寫操作

1個Log thread線程負責將日志緩沖區(qū)刷新到磁盤

1個insert buffer線程負責將寫入緩沖區(qū)內容刷新到磁盤

3、Purge Thread，主要用于回收事務已經(jīng)提交了的undo log，在事務提交之后，undo log 可能不用了，就用它來回收。

4、Page Cleaner Thread，協(xié)助Master Thread 刷新臟頁到磁盤的線程，它可以減輕主線程的壓力，減少阻塞。

事務原理

事務就是一組操作的集合，它是一個不可分割的工作單位，事務會把所有的操作作為一個整體一起向系統(tǒng)提交或撤銷操作請求，即這些操作要么同時成功，要么同時失效。

事務的4大特性分為:

原子性atomicty: 事務是不可分割的最小操作單元，要么全部成功，要么全部失效。
一致性consistency: 事務完成時，必須使所有的數(shù)據(jù)都保持一致狀態(tài)。
隔離性isolation: 數(shù)據(jù)庫系統(tǒng)提供的隔離機制，保證事務在不受外部并發(fā)操作影響的獨立環(huán)境下運行。
持久性durability: 事務一旦提交或回滾，它對數(shù)據(jù)庫中的改變就是永久的。

如何保證事務的4大特性，原子性，一致性和持久性是由innodb存儲引擎底層的兩份日志來保證的，分別是redo log和undo log。對于隔離性是由鎖機制和MVCC(多版本并發(fā)控制)來實現(xiàn)的。

redo log，稱為重做日志，記錄的是事務提交時數(shù)據(jù)頁的物理修改，是用來實現(xiàn)事務的持久性。該日志文件由兩部分組成: 重做日志緩沖redo log buffer及重做日志文件redo log file，前者是在內存中，后者是在磁盤中，當事務提交之后會把所有修改信息都存到該日志文件中，用于在刷新臟頁到磁盤，發(fā)送錯誤時，進行數(shù)據(jù)的恢復使用，從而保證事務的持久性。

具體的操作流程是：

1、客戶端發(fā)起事務操作，包含多條DML語句。首先去innodb中的buffer pool中的數(shù)據(jù)頁去查找有沒有我們要更新的這些數(shù)據(jù)，如果沒有則通過后臺線程從磁盤中加載到buffer pool對應的數(shù)據(jù)頁中，然后就可以在緩沖池中進行數(shù)據(jù)操作了。

2、此時緩沖池中的數(shù)據(jù)頁發(fā)生了變更，還沒刷寫到磁盤，這個數(shù)據(jù)頁稱為臟頁。臟頁不是實時刷新到磁盤的，而是根據(jù)你配置的刷寫策略進行刷寫到磁盤的（
innodb_flush_log_at_trx_commit，0,1,2三個值）。如果臟頁在往磁盤刷新的時候出現(xiàn)了故障，會丟失數(shù)據(jù)，導致事務的持久性得不到保證。為了避免這種現(xiàn)象，當對緩沖池中的數(shù)據(jù)進行增刪改操作時，會把增刪改記錄到redo log buffer當中，redo log buffer會把數(shù)據(jù)頁的物理變更持久化到磁盤文件中(ib_logfile0/ib_logfile1)。如果臟頁刷新失敗，就可以通過這兩個日志文件進行恢復。

undo log，它是用來解決事務的原子性的，也稱為回滾日志。用于記錄數(shù)據(jù)被修改前的信息，作用包括:提供回滾和MVCC多版本并發(fā)控制。

undo log和redo log的記錄物理日志不一樣，它是邏輯日志。可以認為當delete一條記錄時，undo log中會記錄一條對應的insert記錄，當update一條記錄時，它記錄一條對應相反的update記錄，當執(zhí)行rollback時，就可以從undo log中的邏輯記錄讀取到相應的內容并進行回滾。

undo log銷毀: undo log 在事務執(zhí)行時產(chǎn)生，事務提交時，并不會立即刪除undo log，因為這些日子可能用于MVCC。

undo log存儲: undo log 采用段的方式進行管理和記錄，存放在前面介紹的rollback segment回滾段中，內部包含1024個undo log segment。

MVCC

mvcc(multi-Version Concurrency Control),多版本并發(fā)控制，指維護一個數(shù)據(jù)的多個版本，使得讀寫操作沒有沖突，快照讀為MySQL實現(xiàn)MVCC提供了一個非阻塞讀功能，MVCC的具體實現(xiàn)，還需要依賴于數(shù)據(jù)庫記錄中的三個隱式字段，undo log日志、readView。

當前讀，指的是記錄的最新版本，讀取時還要保證其他并發(fā)事務不能修改當前記錄，會對讀取的記錄進行加鎖。對于我們日常的操作，如 select 。。。lock in share mode，select 。。。 for update、update、insert、delete都是一種當前讀。
快照讀，簡單的select(不加鎖)就是快照讀，讀取的是記錄數(shù)據(jù)的可見版本，有可能是歷史數(shù)據(jù)，不加鎖是非阻塞讀。

read committed 每次select 都生成一個快照讀

repeatable read 開啟事務后第一個select語句才是快照讀的地方

serializable 快照讀會退化為當前讀。

mvcc的實現(xiàn)原理

記錄中的隱藏字段 DB_TRX_ID、DB_ROLL_PTR、DB_ROW_ID (ibd2sdi stu.ibd查看表空間)

DB_TRX_ID: 最近修改事務ID，記錄插入這條記錄或最后一次修改該記錄的事務ID

DB_ROLL_PTR: 回滾指針，指向這條記錄的上一個版本，用于配合undo log，指向上一個版本

DB_ROW_ID: 隱藏主鍵，如果表結構沒有指定主鍵，將會生成該隱藏字段。

undo log 回滾日志，在insert、update、delete的時候產(chǎn)生的便于數(shù)據(jù)回滾的日志，當insert的時候，產(chǎn)生的undo log日志只在回滾時需要，在事務提交后可以立即刪除。而update、delete的時候，產(chǎn)生的undo log 日志不僅僅在回滾時需要，在快照讀時也需要，不會立即被刪除。
undo log版本鏈，不同事務或相同事務對同一條記錄進行修改，會導致該記錄的undo log生成一條記錄版本鏈表，鏈表的頭部是最新的舊記錄，鏈表尾部是最早的舊記錄。
readView（讀視圖）,就是快照讀SQL執(zhí)行時mvcc提取數(shù)據(jù)的依據(jù)，記錄并維護系統(tǒng)當前活躍的事務(為提交的)ID，readview中包含了四個核心字段。

m_ids當前活躍的事務ID集合

min_trx_id: 最小活躍事務id

max_trx_id: 預分配事務ID，當前最大事務id+1，因為事務id是自增的

creator_trx_id: ReadView創(chuàng)建者的事務ID

版本鏈數(shù)據(jù)訪問規(guī)則:

trx_id: 表示當前的事務ID

1、trx_id == creator_trx_id? 可以訪問讀版本-->成立的話,說明數(shù)據(jù)是當前這個事務更改的

2、trx_id<min_trx_id?可以訪問讀版本-->成立,說明數(shù)據(jù)已經(jīng)提交了。

3、trx_id>max_trx_id？不可用訪問讀版本-> 成立的話，說明該事務是在ReadView生成后才開啟的。

4、min_trx_id<=trx_id<=max_trx_id？如果trx_id不在m_ids中是可以訪問讀版本的-->成立的話，說明數(shù)據(jù)已經(jīng)提交。

不同的隔離級別，生成ReadView的時機不同:

read committed：在事務中每一次執(zhí)行快照讀時生成ReadView