扒一扒InnoDB數據在硬盤上是如何存放的

NO IMAGE

前言

hello,小夥伴們下午好。俗話說的好,一時拖更一時爽,一直拖更一直爽。但是今天良心發現了,決定要更一下。高能預警,為了還債,特地寫了篇長文。

扒一扒InnoDB數據在硬盤上是如何存放的

索引組織表

在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之後,所以也不會被作為唯一鍵。

扒一扒InnoDB數據在硬盤上是如何存放的

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存儲引擎邏輯結構的最高層,所以的數據都存放在表空間裡面。

在默認情況下,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性能高?

扒一扒InnoDB數據在硬盤上是如何存放的

下圖為行格式Compact的大概結構,先瞅一眼,主要分為兩個部分,額外信息和真實數據。額外信息包括變成字段長度,NULL值列表,記錄頭信息,真實數據即為該行記錄有多少列,每列數據有哪些。其中記錄頭信息包括記錄刪除位,記錄類型,下一個指針的位置。

注意,記錄頭信息還有很多為其他信息,但是重要的就這幾個。是不是不知道他們是幹撒的,一臉懵逼中,沒事,這還是混個臉熟,下一部分來慢慢盤他。

扒一扒InnoDB數據在硬盤上是如何存放的

變長字段長度

MySQL支持一些變長的數據類型,如varchar,text,blob,變長長度存儲多少字節的數據是不固定的,所以我們在存儲真實數據的時候,需要將這些數據佔用的字節數也要存儲起來。

剛才我們新增了兩條數據,先拿第一個數據為例,將真正數據佔用的字節長度都存放在記錄的開頭部位,從而形成一個變長字段長度列表,逆序存放。如下圖,所以最終第一條記錄存放的十六進制為08 04 03,他們之間沒有空格,是為了顯示的效果才加了空格。那第二條記錄很明顯是03 03.

注意:如果表中沒有變長字段,則該字段不存在。

扒一扒InnoDB數據在硬盤上是如何存放的

NULL值列表

我們知道表中的某些列可能存儲NULL值,如果這些NULL值放在記錄的真實數據中存儲會佔用空間,所以Compact將這些值為NULL的列統一管理起來,存儲在NULL表中。

注意:跟變長字段一樣,如果表中沒有NULL值的列,則該字段不存在。

注意:MySQL規定NULL值列表必須是整數個字節的位表示,如果使用的二進制位歌手不是整數個字節,則在字節的高位補0.

第一行數據雖然沒有NULL值,但是a,c是可能存儲NULL值的列,所以NULL值列表如下,0表示列所對應的值不為NULL,1表示列所對應的值為NULL。

扒一扒InnoDB數據在硬盤上是如何存放的

第二行數據a不是NULL,c是NULL,所以對應的NULL值列表如下。

扒一扒InnoDB數據在硬盤上是如何存放的

記錄頭信息

  • 記錄刪除位(delete_mask):0為未刪除,1為刪除
  • 記錄類型(record_type):0表示普通記錄,1表示B+樹非葉子節點記錄,2表示最小記錄,3表示最大記錄。
  • 下一個指針的位置(next_record):表示從當前記錄的真實數據到下一條記錄的真實數據之間的地址偏移量。比如第一條記錄的next_record為20,那麼意味從第一條記錄的真實數據的地址處向後找32個字節便是下一條記錄的真實數據。實際上就是鏈表結構。

真實數據

InnoDB數據頁結構(重點)

下圖為數據頁的整體結構,咱先了解個大概,再慢慢盤他。

扒一扒InnoDB數據在硬盤上是如何存放的

文件頭(File Header)

頁的一些通用信息,包括該頁屬於哪個表空間,InnoDB存儲引擎頁的類型。

頁頭(Page Header)

記錄數據頁的狀態信息。

最小記錄+最大記錄(Infimum+supermum)

在InnoDB存儲引擎中,每個數據頁都有兩條虛擬的行記錄,用來限定記錄的邊界。

Infimum記錄是指比該頁中任何主鍵值都要小的值,Supermum記錄是指比該頁中任何主鍵值都要大的值。

這兩個值在頁創建時都會被的創建,並且在任何情況下不會被刪除。

這兩條記錄的構造十分簡單,都是有5個字節大小的記錄頭信息和8個字節的固定部分組成的。

注意:上面提到了最小記錄的record_type為2,最大記錄的record_type為3。

用戶記錄(User Records)

重點來了,這邊是數據實際存儲位置,上面已經針對行格式做了詳細的劃分,現在咱就長話短說啦。

如果我刪除了第二行記錄,這條記錄並不是立刻刪除了,只是將刪除記錄位改為1啦。並且將他前面一條數據的指針指向他後面一條數據的地址,從而跳過這一條數據。

至於為什麼會這樣做呢?是為了節約時間和空間的消耗。如果在刪除的時候,立刻從磁盤上移除,那麼其他記錄在磁盤上重新排列需要性能消耗,所以在刪除的時候,只會將所有被刪除的記錄組成一個垃圾鏈表,稍後操作。或者有新紀錄插入的時候,覆蓋掉剛才的存儲空間。

扒一扒InnoDB數據在硬盤上是如何存放的

空閒空間(Free Space)

不重要。

頁面目錄(Page Directory)

我們現在已經找到記錄在頁面中按照主鍵由小到達順序組成一個單鏈表,那如果想根據主鍵查詢頁中的某條記錄怎麼辦?

最蠢的方法肯定是按單鏈表的順序從頭到尾的查找,因為只有知道前面一條記錄的記錄的地址,才能根據指針找到下一條記錄。但是這個有個明顯的缺點,就是太慢了,如果有1000條數據,一個個的查詢,如果最後一條記錄才滿足條件,那就太浪費時間啦。

我們可以先從順序表中想想,如果順序表中要找一個記錄,我們除了從頭開始查之外,還可以採用二分法,可以提升查詢速度。

那麼在單鏈表中是否可以採用二分法呢?答案是肯定的。即採用目錄的形式,將所有的記錄劃分為多個記錄塊,然後取每個記錄塊的最大的值,將其組成一個目錄,在查找的時候,先查目錄,能判斷在哪個區間內。這個過程就類似於在書中找到某一個概念,要從目錄先找一樣。

文章尾部(File Tailer)

不重要。哈哈哈。

結束

碼字不易,請多多關注哦。

扒一扒InnoDB數據在硬盤上是如何存放的

寫在最後

該篇借鑑的博文,書籍包括如下,特此感謝!

《MySQL技術內幕——InnoDB存儲引擎》

MySQL是如何運行的

blog.csdn.net/u010922732/…

juejin.im/post/5cb3e3…

相關文章

全網最全最詳細的ShardingJDBC入門

ShardingJDBC掃盲篇

不要為了“分庫分表”而“分庫分表”

詳解B+樹及其正確打開方式