扒一扒InnoDB數據在硬盤上是如何存放的
本文轉載自微信公眾號「學習Java的小姐姐」，轉載本文請聯系學習Java的小姐姐公眾號。
索引組織表
在InnoDB存儲引擎中，表都是按照主鍵順序組織存放的，這種存儲方式的表被稱為索引組織表。
在InnoDB中，每張表都有各自的主鍵(Primary Key)，如果在創建表的時候顯式的定義主鍵，則InnoDB存儲引擎會按如下方式選擇或創建主鍵。
首先判斷表中是否有非空的索引，如果有則第一個定義的非空索引作為主鍵
如果不符合上述條件，InnoDB存儲引擎自動創建一個6個字節大小的指針
這樣的描述太干癟啦，我們來動手操作下。
1.選擇第一個定義的非空索引
首先，我們創建表student，并填充兩條測試數據，語句如下：
- create table student(
- a int ,
- b int not null,
- c int not null,
- UNIQUE key (a),
- UNIQUE key (c),
- UNIQUE key (b)
- );
- insert into student select 1,2,3;
- insert into student select 4,5,6;
運行結果如下，我們可以看出_rowid的值等于列c的值，那就說明當前存儲的結構是將c作為主鍵的。另外a是可以為空的，雖然他定義唯一鍵的是第一個，但仍然不會作為主鍵。b雖然是先定義列，但是定義唯一鍵是在c之后，所以也不會被作為唯一鍵。
2.自動創建6個字節大小的指針
首先，我們創建表score，并填充兩條測試數據，語句如下：
- create table score(
- a int ,
- b int ,
- c int,
- UNIQUE key (a),
- UNIQUE key (c),
- UNIQUE key (b)
- );
- insert into score select 1,2,3;
- insert into score select 4,5,6;
運行結果如下，直接報錯了，不認為_rowid是他的列名，因為沒有滿足條件的列能成為他的主鍵，所以其就自動創建指針來解決問題啦。
InnoDB的邏輯存儲結構(整體)
表空間
表空間可以看做是InnoDB存儲引擎邏輯結構的最高層，所以的數據都存放在表空間里面。
在默認情況下，InnoDB存儲引擎有一個共享表空間ibdata1，即所有數據都存放在這個表空間里面。當然也可以在my.ini參數文件中啟用innodb_file_per_table，則每張表的數據就可以單獨放在一個表空間中。
注意：即使啟用innodb_file_per_table參數，一些回滾信息，系統事務信息等還是在共享的表空間中，其隨著時間的變化大小還是會不斷增大的。單獨的表空間只會存放一些數據及索引信息。
段
在InnoDB存儲引擎中，對段的管理都是由引擎自身所完成的，DBA不能也沒必要對其進行控制。
區
區是由連續頁組成的空間，在任何情況下每個區的大小都是1MB，頁的大小為16kb，所以一個區一共有64個連續的頁。
頁
下面詳細描述。
行
下面詳細描述。
InnoDB行記錄格式(重點)
InnoDB存儲引擎和大多數數據庫一樣，記錄是以行的形式純純的，這就是意味著頁中保存著表的一行行數據。那么問題就來了，他這一行數據是包括哪些部分，除了具體的數據，還有其他的一些額外信息嗎?
首先，我們先來看一下如果沒有指定行格式，其默認的行格式是什么?
新建表test，擁有的字段a，b ，c 。
- create table test(
- a varchar(10),
- b varchar (10) not null,
- c char(10)
- );
- insert into test values( '001','Andy','compter');
- insert into test values( '002','Bob',NULL);
如下圖所示，默認的行格式是Compact ，該行格式是在MySQL5.0中引入的，其設計目標是高校的存儲數據。簡單來說，一個頁存放的行數據越多，其性能越高。針對這個描述，咱先放在一邊，之后看到其他的行格式，咱對比著看，為啥compact性能高?
下圖為行格式Compact的大概結構，先瞅一眼，主要分為兩個部分，額外信息和真實數據。額外信息包括變成字段長度，NULL值列表，記錄頭信息，真實數據即為該行記錄有多少列，每列數據有哪些。其中記錄頭信息包括記錄刪除位，記錄類型，下一個指針的位置。
注意，記錄頭信息還有很多為其他信息，但是重要的就這幾個。是不是不知道他們是干撒的，一臉懵逼中，沒事，這還是混個臉熟，下一部分來慢慢盤他。
變長字段長度
MySQL支持一些變長的數據類型，如varchar,text,blob,變長長度存儲多少字節的數據是不固定的，所以我們在存儲真實數據的時候，需要將這些數據占用的字節數也要存儲起來。
剛才我們新增了兩條數據，先拿第一個數據為例，將真正數據占用的字節長度都存放在記錄的開頭部位，從而形成一個變長字段長度列表，逆序存放。如下圖，所以最終第一條記錄存放的十六進制為08 04 03，他們之間沒有空格，是為了顯示的效果才加了空格。那第二條記錄很明顯是03 03.
注意：如果表中沒有變長字段，則該字段不存在。
NULL值列表
我們知道表中的某些列可能存儲NULL值，如果這些NULL值放在記錄的真實數據中存儲會占用空間，所以Compact將這些值為NULL的列統一管理起來，存儲在NULL表中。
注意：跟變長字段一樣，如果表中沒有NULL值的列，則該字段不存在。注意：MySQL規定NULL值列表必須是整數個字節的位表示，如果使用的二進制位歌手不是整數個字節，則在字節的高位補0.
第一行數據雖然沒有NULL值，但是a,c是可能存儲NULL值的列，所以NULL值列表如下，0表示列所對應的值不為NULL,1表示列所對應的值為NULL。
第二行數據a不是NULL，c是NULL，所以對應的NULL值列表如下。
記錄頭信息
- 記錄刪除位(delete_mask):0為未刪除，1為刪除
- 記錄類型(record_type)：0表示普通記錄，1表示B+樹非葉子節點記錄，2表示最小記錄，3表示最大記錄。
- 下一個指針的位置(next_record)：表示從當前記錄的真實數據到下一條記錄的真實數據之間的地址偏移量。比如第一條記錄的next_record為20，那么意味從第一條記錄的真實數據的地址處向后找32個字節便是下一條記錄的真實數據。實際上就是鏈表結構。
InnoDB數據頁結構(重點)
下圖為數據頁的整體結構，咱先來了解下大概，再慢慢盤它。
文件頭(File Header)
頁的一些通用信息，包括該頁屬于哪個表空間，InnoDB存儲引擎頁的類型。
頁頭(Page Header)
記錄數據頁的狀態信息。
最小記錄+最大記錄(Infimum+supermum)
在InnoDB存儲引擎中，每個數據頁都有兩條虛擬的行記錄，用來限定記錄的邊界。
Infimum記錄是指比該頁中任何主鍵值都要小的值，Supermum記錄是指比該頁中任何主鍵值都要大的值。
這兩個值在頁創建時都會被的創建，并且在任何情況下不會被刪除。
這兩條記錄的構造十分簡單，都是有5個字節大小的記錄頭信息和8個字節的固定部分組成的。
注意：上面提到了最小記錄的record_type為2，最大記錄的record_type為3。
用戶記錄(User Records)
重點來了，這邊是數據實際存儲位置，上面已經針對行格式做了詳細的劃分，現在咱就長話短說啦。
如果我刪除了第二行記錄，這條記錄并不是立刻刪除了，只是將刪除記錄位改為1啦。并且將他前面一條數據的指針指向他后面一條數據的地址，從而跳過這一條數據。
至于為什么會這樣做呢?是為了節約時間和空間的消耗。如果在刪除的時候，立刻從磁盤上移除，那么其他記錄在磁盤上重新排列需要性能消耗，所以在刪除的時候，只會將所有被刪除的記錄組成一個垃圾鏈表，稍后操作。或者有新紀錄插入的時候，覆蓋掉剛才的存儲空間。
空閑空間(Free Space)
不重要。
頁面目錄(Page Directory)
我們現在已經找到記錄在頁面中按照主鍵由小到達順序組成一個單鏈表，那如果想根據主鍵查詢頁中的某條記錄怎么辦?
最蠢的方法肯定是按單鏈表的順序從頭到尾的查找，因為只有知道前面一條記錄的記錄的地址，才能根據指針找到下一條記錄。但是這個有個明顯的缺點，就是太慢了，如果有1000條數據，一個個的查詢，如果最后一條記錄才滿足條件，那就太浪費時間啦。
我們可以先從順序表中想想，如果順序表中要找一個記錄，我們除了從頭開始查之外，還可以采用二分法，可以提升查詢速度。
那么在單鏈表中是否可以采用二分法呢?答案是肯定的。即采用目錄的形式，將所有的記錄劃分為多個記錄塊，然后取每個記錄塊的最大的值，將其組成一個目錄，在查找的時候，先查目錄，能判斷在哪個區間內。這個過程就類似于在書中找到某一個概念，要從目錄先找一樣。
文章尾部(File Tailer)
不重要。哈哈哈。
寫在最后
寫在最后
該篇借鑒的博文，書籍如下。
《MySQL技術內幕——InnoDB存儲引擎》MySQL是如何運行的https://blog.csdn.net/u010922732/article/details/82994253#%E4%B8%80%20%E5%AD%98%E5%82%A8%E5%BC%95%E6%93%8E%E4%BD%9C%E7%94%A8%E4%BA%8E%E4%BB%80%E4%B9%88%E5%AF%B9%E8%B1%A1
https://juejin.im/post/5cb3e3dfe51d456e3428c0db
