MySQL技術內幕(一) InnoDB存儲引擎

A.iguodala 2021-08-16 02:05:35 阅读数:86

本文一共[544]字,预计阅读时长:1分钟~
mysql innodb 引擎

1. InnoDB 體系架構

InnoDB 存儲引擎有多個內存塊,可以認為這些內存塊組成一個大的內存池。

後臺線程的主要作用是負責刷新內存池中的數據,保證內存池中的內存緩存的是最近的數據是最近的數據,此外將已修改的數據文件刷新到磁盤文件,同時保證在數據庫發生异常的輕快下InnoDB能恢複到正常運行狀態。

簡單來說,就是相當於一個小型的操作系統,後臺線程相當於CPU,內存池相當於內存,文件就是磁盤。

在這裏插入圖片描述

1.1 後臺線程

InnoDB存儲引擎是多線程的模型,因此其後臺有多個不同的後臺線程,負責處理不同的任務

  • Master Thread

    • Master Thread是一個非常核心的後臺線程,主要負責將緩沖池中的數據异步刷新到磁盤,保證數據的一致性、合並插人緩沖(INSERT BUFFER)等。
  • IO Thread

    • 在InnoDB 存儲引擎中大量使用了AIO來處理寫IO請求,極大提高了數據庫的性能。可以通過show engine InnoDB status 命令查看
    • 在這裏插入圖片描述
  • Purge Thread

    • 事務被提交後,其所使用的undolog可能不再需要,因此需要PurgeThread來回收已經使用並分配的undo頁。
  • Page Cleaner Thread

    • 進行刷新髒頁的操作。

1.2 內存

① 緩沖池

  • InnoDB存儲引擎是基於磁盤存儲的,並將其中的記錄按照頁的方式進行管理。為了解决CPU速度與磁盤速度不匹配的問題,通常使用緩沖池技術來提高數據庫的整體性能。
  • 在讀取頁的時候,首先從磁盤讀到的頁放在緩沖池中,下一次讀取相同的頁就不需要在進行磁盤IO,如果沒有命中就要去磁盤讀取。
  • 修改操作的時候,則先修改緩沖池中的頁,再以一定得頻率刷新到磁盤上。(刷新回磁盤的操作是通過Checkpoint機制刷新回磁盤,下面會介紹)。
  • 具體來看,緩沖池中緩存的數據頁類型有:索引頁、數據頁、undo頁、插入緩沖( insert buffer)、自適應哈希索引(adaptive hash index)、InnoDB存儲的鎖信息(lockinfo)、數據字典信息(data dictionary〉等。

在這裏插入圖片描述

  • 在InnoDB 1.x之後,允許有多個緩沖池實例,每個頁根據哈希值平均分配到不同的緩沖池中,可以减少數據庫內部競爭,提高並發處理能力。

② LRU List、Free List 和 Flush List

InnoDB 存儲引擎主要通過這三個鏈錶對緩沖池的內存區域進行管理。

  • LRU List:在InnoDB 存儲引擎中,緩沖池中頁的大小默認為16KB,使用LRU算法進行管理,但是在LRU的基礎上進行了一些改進。
    • 新讀取到的頁並不是直接放在LRU列錶的首部,而是放在midpoint比特置(默認5/8處)。
    • 因為一些索引或數據掃描操作,可能需要訪問非常多的頁,而這些頁可能只是在此次使用,為了避免這些頁將真正的熱點數據移除,而采用這種形式。
    • InnoDB 又引入了一個innodb_old_blocks_time參數,如果讀取到的頁經過多少時間,才會被放到LRU列錶的熱端。
    • 另外 InnoDB 1.0.x版本之後支持壓縮頁功能。
  • Free List:LRU列錶管理已經讀取的頁,Free列錶管理空閑的頁,例如當數據庫啟動的時候LRU列錶是空的,讀取進入頁之後先向Free列錶請求頁,然後删除Free列錶的頁,加入LRU列錶中,當Free列錶沒有頁了再進行頁面置換。
  • Flush List:在LRU列錶中的頁誒修改之後,就稱之為髒頁,即緩沖池中的頁和磁盤上的頁數據產生了不一致,Flush 列錶的頁就是髒頁的列錶。

③ 重做日志緩沖

  • InnoDB存儲引擎首先將重做日志信息先放入到這個重做日志緩沖區,然後按一定頻率將其刷新到重做日志文件。默認大小為8MB。
  • 以下三種情况會將重做日志緩沖中的內容刷新到外部磁盤的重做日志文件中:
    • Master Thread每一秒將重做日志緩沖刷新到重做日志文件;
    • 每個事務提交時會將重做日志緩沖刷新到重做日志文件;
    • 當重做日志緩沖池剩餘空間小於1/2時,重做日志緩沖刷新到重做日志文件。

④ 額外的內存池

  • 在InnoDB存儲引擎中,對內存的管理是通過一種稱為內存堆(heap)的方式進行的。
  • 在對一些數據結構本身的內存進行分配時,需要從額外的內存池中進行申請,當該區域的內存不够時,會從緩沖池中進行申請。

1.3 Checkpoint 技術

Checkpoint(檢查點) 技術的目的主要就是解决以下問題

  • 縮短數據庫的恢複時間
    • 數據庫發生宕機時,數據庫不需要重做所有的日志,因為Checkpoint之前的頁都已經刷新到磁盤,只需要重做Checkpoint之後的日志,縮短了恢複時間。
  • 緩沖池不够用時,將髒頁刷新到磁盤
    • 如果緩沖池不够用的情况下,LRU需要進行頁面置換,如果被置換的頁是髒頁,則强制執行Checkpoint,將改頁寫回磁盤。
  • 重做日志不可用時,刷新髒頁
    • 因為重做日志基本都是重複使用,如果要被覆蓋的重做日志的內容還沒有被寫回磁盤,則强制執行Checkpoint,將那些頁刷新到磁盤。

1.5 Master Thread 工作方式

在這裏插入圖片描述
InnoDB 存儲引擎的主要工作都是在一個單獨的後臺線程 Master Thread 中完成的。

lnnoDB 1.0.x版本之前的Master Thread

Master Thread 具有最高的線程優先級別。其內部由多個循環組成。

循環中每秒一次的操作包括:

  • 日志緩沖刷新到磁盤,即時這個事務還沒有提交(總是)。
    • 即使事務沒有提交,每秒一次的刷新操作也會將重做日志緩沖中的內容刷新到磁盤,所以很大的事務提交時間也很短。
  • 合並插入緩存(可能)
    • 存儲引擎會價差當前一秒發生的IO次數是否小於五次,小於則認為IO壓力小,可以進行插入緩沖操作。
  • 至多可以刷新100個緩沖池中的髒頁到磁盤。
  • 如果當前沒有用戶活動,則切換到後臺循環,節省資源。

每十秒進行一次的操作:

  • 刷新100個髒頁到磁盤(可能)。
    • 存儲引擎會檢查過去十秒的IO操作次數,小於兩百則由足够的IO能力,則可以將100個髒頁刷新回磁盤。
    • 另外存儲引擎會判斷髒頁的比例如果大於70% 則回收100個,如果小於,則需要刷新10%(一定會發生)。
  • 合並至多5個插入緩沖(總是)。
  • 將日志緩沖刷新到磁盤(與每一秒做的操作一致)。
  • 删除無用的 Undo 頁,會判斷哪些 Undo 頁可以删除,最多回收20個。

後臺線程循環(background loop):若當前沒有用戶活動(數據庫空閑時)或者數據庫關閉( shutdown),就會切換到這個循環。background loop會執行以下操作:

  • 删除無用的Undo頁
  • 合並20個插入緩沖
  • 跳回到主循環。
  • 跳轉到flush loop 刷新100個頁直到符合條件。

如果flush loop 也無事可做,可能會切換到suspend_loop 暫停循環,將主線程掛起。

lnnoDB 1.2.x版本之前的Master Thread

增加了一些關於髒頁,插入緩沖以及 Undo頁的設置選項,在設備允許的情况下,可以進行自定義,增强刷新的頁數等。

lnnoDB 1.2.x版本將的Master Thread

將刷新髒頁的線程分離到了一個單獨的 Page Cleaner Thread。

1.6 InnoDB 關鍵特性

InnoDB存儲引擎的關鍵特性包括:

  • 插入緩沖(Insert Buffer)
  • 兩次寫( Double Write)
  • 自適應哈希索引(Adaptive Hash Index)
  • 异步IO (Async IO)
  • 刷新鄰接頁(Flush Neighbor Page)

1.6.1 插入緩沖(Insert Buffer)

  1. Insert Buffer

主鍵是行唯一的標識符,通常應用程序中行記錄的插入順序是按照主鍵主鍵遞增的順序進行插入的。但是對於非聚集索引葉子節點的插入不再是順序的了,這時就需要離散地訪問非聚集索引頁。

所以InnoDB 設計了插入緩沖:

  • 對於非聚集索引的插入或更新操作,不是每一次直接插入到索引頁中,而是先判斷插入的非聚集索引頁是否在緩沖池中。
  • 如果在,直接插入,不在則先放入到 Insert Buffer 中。
  • 然後再以一定的頻率以及情况進行 Insert Buffer 和輔助索引葉子節點的合並操作。
  • 這時通常能將多個插入操作合並到一個操作,因為存在於同一個索引頁,從而提供性能。

Insert Buffer 的使用需要同時滿足以下兩個條件:

  • 索引是輔助索引( secondary index);
  • 索引不是唯一(unique)的。
  1. Change Buffer

InnoDB 從1.0.x版本開始引入了Change Buffer,可將其視為Insert Buffer 的昇級。從這個版本開始,InnoDB存儲引擎可以對DML 操作 ----- INSERT、DELETE、UPDATE都進行緩沖,他們分別是:Insert Buffer、Delete Buffer、Purge buffer。

  1. Insert Buffer 的內部實現

Insert Buffer 的數據結構是一棵B+樹,由葉子節點和非葉子節點組成。

非葉子節點 存放的是查詢的search key (一共占用9個字節)。也就是數據錶到具體物理比特置的映射。

在這裏插入圖片描述

  • space:錶示待插入記錄所在錶的錶空間id,每個錶有一個唯一的 space id 占用4字節;
  • marker占用1字節,用來兼容老版本的 Insert Buffer;
  • offset 錶示頁所在的偏移量,占用4字節;

當一個輔助索引要插入頁時,如果該頁不在緩沖池中,則會根據以上規則構造一個 search key ,然後查詢該B+樹,將記錄插入到對應的葉子節點。

葉子節點記錄如下:前三個字段和search key 的字段一樣,metadata 字段記錄一些標志,從第五個字段開始存儲實際插入記錄的各個字段。

在這裏插入圖片描述
為了方便合並插入緩沖區的一些操作,還需要維護一個特殊的頁來記錄每個輔助索引頁的一些信息。稱為 Insert Buffer Bitmap

在這裏插入圖片描述

  1. Merge Insert Buffer

Insert Buffer 中的記錄何時合並到真正的輔助索引中:

  • 輔助索引頁被讀取到緩沖池時;
    • 如果輔助索引頁被讀取到緩沖池,例如通過SELECT 查詢讀取,則檢查Insert Buffer Bitmap ,檢查該索引頁是否有記錄存在於Insert Buffer 中,如果有,則插入該記錄。
  • Insert Buffer Bitmap頁追踪到該輔助索引頁已無可用空間時;
  • Master Thread 每一秒或者十秒一次的合並操作。

1.6.2 兩次寫

InnoDB存儲引擎正在寫入某個頁到錶中,而這個頁只寫了一部分,數據庫就宕機了,這種情况稱為部分寫失效

這時會想到的是使用redo日志進行操作,但是redo日志記錄的是對頁的物理操作,如果頁本身已經發生損壞,則是沒有意義的,所以采用在使用redo重做日志之前,用戶需要一個頁的副本,當寫入失效發生時,先通過頁的副本來還原該頁,再進行重做。這就稱為兩次寫(double write)

具體實現步驟為:

  • 對數據緩沖池中的髒頁進行刷新時,並不直接寫磁盤。
  • 而是會通過memcpy函數將髒頁先複制到內存中的double write buffer。
  • 之後通過double write buffer再分兩次、每次1MB順序寫入共享錶空間的物理磁盤上。
    • 因為該過程寫入磁盤的空間是連續的,所以,IO的效率很高。
  • 然後馬上調用fsync函數,同步髒頁進磁盤上。

1.6.3 自適應哈希索引

InnoDB存儲引擎會監控對錶上各索引頁的查詢。如果觀察到建立哈希索引可以帶來速度提昇,則建立哈希索引,稱之為自適應哈希索引(Adaptive Hash Index,AHI)。也就是說存儲引擎會自動根據訪問的頻率和模式來自動地為某些熱點頁建立哈希索引。

建立哈希索引的要求如下:

  • 使用同樣的查詢條件訪問了 100 次。
  • 或者是頁通過該查詢條件訪問了 N 次,N = 頁中記錄 / 16;

1.6.4 异步IO

為了提高磁盤操作性能,當前的數據庫系統都采用异步IO (Asynchronous IO,AIO)的方式來處理磁盤操作。

所謂异步IO就是,應用進程給操作系統發送一個請求後立刻返回,告訴操作系統需要什麼數據,放在哪裏,操作系統將數據准備好,並且從內核緩沖區直接映射到內存中,並給應用進程發送一個完成信號,則數據就可以使用。

數據庫使用异步IO主要有兩點優勢:

  • 在需要訪問多個索引頁的情况下,如果是同步IO,則需要發送一個IO請求,阻塞讀取之後再發送一個IO請求,而异步IO則可以以例如流水線的方式,發出多個IO請求,等待IO操作的處理。
  • 使用AIO連續發送多個IO請求的情况下,如果有連續的頁面,則AIO底層可以優化為一個IO請求。

1.6.5 刷新鄰接頁

InnoDB存儲引擎還提供了Flush Neighbor Page(刷新鄰接頁)的特性。其工作原理為:當刷新一個髒頁時,InnoDB存儲引擎會檢測該頁所在區( extent〉的所有頁,如果是髒頁,那麼一起進行刷新。這樣做的好處顯而易見,通過AIO可以將多個IO寫入操作合並為一個IO操作,故該工作機制在傳統機械磁盤下有著顯著的優勢。

1.7 啟動、關閉與恢複

在InnoDB 存儲引擎關閉以及恢複的時候,可以通過一些參數,來設置一些策略。

參數 innodb_fast_ shutdown 影響著關閉行為:值可以為0、1 或者 2

  • 0 錶示完成所有 full purge (無用Undo 頁的删除)和 merge insert buffer (插入緩沖的合並),以及將髒頁寫回磁盤。
  • 1 錶示只需要將髒頁寫回磁盤,是默認設置。
  • 2 錶示所有都不做,只是將內容寫入日志。

參數 innodb_force_recovery 可以設置InnoDB引擎的恢複策略,因為有時通過事務回滾等操作,可能恢複的時間更長。

  • 1(SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的 corrupt 頁。
  • 2(SRV_FORCE_NO_BACKGROUND):阻止 Master Thread線程的運行。
  • 3(SRV_FORCE_NO_TRX_UNDO):不進行事務的回滾操作。
  • 4(SRV_FORCE_NO_IBUF_MERGE):不進行插入緩沖的合並操作。
  • 5(SRV_FORCE_NO_UNDO_LoG_SCAN):不查看撤銷日志(Undo Log),InnoDB存儲引擎會將未提交的事務視為已提交。
  • 6(SRv_FORCE_NO_LOG_REDO):不進行前滾的操作。

2. 文件

2.1 參數文件

參數文件用於 MySQL 啟動時的初始化參數,這些參數設置了相關的一些特性。

參數分為兩類:

  • 動態參數:指在運行期間可以修改的參數。
  • 靜態參數:指在運行期間不可修改的參數。

2.2 日志文件

日志文件記錄了影響 MySQL 數據庫的各種類型活動,常見的包括以下幾類:

  • 錯誤日志(error log)
  • 二進制日志(binlog)
  • 慢查詢日志(slow query log)
  • 查詢日志(log)

2.2.1 錯誤日志

錯誤日志文件對MySQL的啟動、運行、關閉過程進行了記錄。遇到問題時應該首先查看該文件以便定比特問題。該文件不僅記錄了所有的錯誤信息,也記錄一些警告信息或正確的信息。

可通過該命令查看錯誤文件的比特置信息:

在這裏插入圖片描述

2.2.2 慢查詢日志

慢查詢日志(slow log)可以定比特存在問題的SQL語句,從而進行SQL 層面的優化,例如設置一個閾值,將查詢時間超過該值的SQL語句都記錄到慢查詢日志文件中。

對於慢查詢日志,主要先要了解以下參數:

  • slow_query_log:是否開啟慢查詢日志,默認OFF,開啟則設置為 ON。
  • slow_query_log_file:慢查詢日志文件存儲比特置。
  • log_queries_not_using_indexes :是否把沒有使用到索引的SQL記錄到日志中,默認OFF,開啟則設置為 ON。
  • long_query_time:超過多少微秒的查詢才會記錄到日志中,5.1版本之後,單比特采用微妙。
  • log_output:慢查詢日志輸出比特置,默認為FILE 文件的形式,可以改成輸出到 mysql 庫下的slow_log錶,修改該參數為 TABLE。

開啟慢查詢日志的方法也主要分為兩種:

  • 執行語句設置(這個方法重啟MySQL後會失效)
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL slow_query_log_file = '文件路徑(絕對路徑)';
SET GLOBAL log_queries_not_using_indexes = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL log_output = 'TABLE';
  • 寫入配置文件(重啟MySQL 不會失效,修改後需要重啟)
slow_query_log="ON"
slow_query_log_file="文件路徑(絕對路徑)"
log_queries_not_using_indexes="ON"
long_query_time=1

例如使用執行一條SQL沒有用到索引:

在這裏插入圖片描述

則可以在slow_log 錶中顯示:

在這裏插入圖片描述

2.2.3 查詢日志

查詢日志記錄了所有對數據庫的請求的信息,無論這些請求是否得到了正確的執行。

通過設置 general_log 參數開啟,並且通過 log_output 參數可以設置在 mysql庫下的 general_log 錶中顯示。

2.2.4 二進制日志

二進制日志(binary log)記錄了對MySQL數據庫執行更改的所有操作,但是不包括SELECT 和SHOW這類操作,因為這類操作對數據本身並沒有修改。

二進制文件主要作用:

  • 恢複(recovery):某些數據的恢複需要二進制文件。
  • 複制(replication):原理和恢複類似,通過複制和執行二進制日志使一臺遠程的MySQL 數據庫(從)和一臺主MySQL 數據庫進行同步。
  • 審計(audit):用戶可以通過二進制日志中的信息來進行審計,判斷是否有對數據庫進行注入的攻擊。

二進制日志通過配置 log-bin 參數為ON則開啟

以下配置文件參數影響二進制日志記錄的信息和行為:

  • max_binlog _size:單個二進制文件的最大值,超過則生成下一個文件。
  • binlog_cache_size:在事務中未提交的二進制日志會被記錄到二進制日志緩存中,提交後會寫入到真的二進制文件。
  • sync_binlog:該參數定義了什麼時候將二進制日志寫入磁盤的時機。
  • binlog-do-db:錶示需要寫入哪些庫的日志。
  • binlog-ignore-db:錶示需要忽略哪些庫的日志。
  • log-slave-update:一般情况下,如果某個數據庫複制的是一個從機,則不會從他那取得二進制日志並寫入到自己的日志中,如果需要寫入,則配置該參數。
  • binlog _format:規定了二進制日志的存儲格式。主要有三種:
    • STATEMENT:存儲SQL 語句,存儲空間小,但是對於類似rand()等確定操作,會造成主從數據不一致。
    • ROW:存儲錶的行更改情况,空間較大,不可讀取。
    • MIXED:兩種混用。

二進制日志通過 MySQL 提供的 mysqlbinlog 查看。

還有一些與存儲引擎無關的文件,包括 ① 套接字文件:參數UNIX系統下本地連接MySQL 的套接字方式;② pid 文件:存儲了進程ID;③ 錶結構定義文件:以frm為結尾,記錄了錶的結構定義。

2.4 InnoDB 存儲引擎文件

2.4.1 錶空間文件

InnoDB采用將存儲的數據按錶空間(tablespace)進行存放的設計。在默認配置下會有一個初始大小為10MB,名為ibdata1的文件。該文件就是默認的錶空間文件( tablespace file)。

設置 innodb_data_file_path 參數後,所有基於InnoDB存儲引擎的錶的數據都會記錄到該共享錶空間中。

設置了參數 innodb_file_per_table,則用戶可以將每個基於InnoDB存儲引擎的錶產生一個獨立錶空間。後綴為ibd。

2.4.2 重做日志文件

重做日志(redo log)記錄了對於InnoDB存儲引擎的事務日志。

每個InnoDB存儲引擎至少有一個重做日志文件組,每個組下又至少有兩個重做日志文件。以循環的方式寫入,例如先寫文件1,文件1寫滿之後,寫文件2,文件2滿了之後,又重新寫文件1,因為文件1的內容會被覆蓋,所以會有一個 capacity 閾值,檢測 check point 是否已經將該部分內容寫回到磁盤,如果沒有,則從髒頁列錶中選擇部分髒頁寫回磁盤。

redo log 和 bin log 的區別?

  1. 服務範圍不同:binlog 會記錄各種存儲引擎的事務日志,而 redolog 只關乎 InnoDB 引擎本身。
  2. 記錄內容不同:binlog 有STATEMENT 和 ROW 格式,分別記錄的是SQL語句和行的修改情况。而 redolog 則記錄的是對於頁更改的物理情况。
  3. 寫入時間不同:對於一個事務,binlog 會在提交時一次寫完,而 redolog,在事務進行時就不斷寫入。

重做日志結構:

在這裏插入圖片描述

  • redo_log_type:占用Ⅰ字節,錶示重做日志的類型;
  • space:錶示錶空間的ID,但采用壓縮的方式,因此占用的空間可能小於4字節;
  • page_no:錶示頁的偏移量,同樣采用壓縮的方式
  • redo_log_body:錶示每個重做日志的數據部分,恢複時需要調用相應的函數進行解析

從重做日志緩沖往磁盤寫入時,是按512個字節,也就是一個扇區的大小進行寫人。因為扇區是寫入的最小單比特,因此可以保證寫入必定是成功的。

從重做日志緩沖寫入磁盤的條件一般包括兩個:

  • Master Thread 的定時循環操作。
  • 由參數 innodb_flush _log _at_trx_commit 控制,錶示在提交(commit)操作時,對緩沖進行處理。
    • 有三個可用參數,0、1 和 2;
    • 0 錶示事務提交不處理緩沖區,而等待每秒一次的主線程循環。
    • 1 錶示事務提交就同步的將重做日志緩沖區寫到磁盤。為了保證事務的持久性,就必須采用這種策略。
    • 2 錶示事務提交通過异步的方式將重做日志緩沖區寫到磁盤。並不能保證該事件一定發生。

3. InnoDB 邏輯存儲結構

從InnoDB存儲引擎的邏輯存儲結構看,所有數據都被邏輯地存放在一個空間中,稱之為錶空間( tablespace)。錶空間又由(segment)、(extent)、(page)組成。

在這裏插入圖片描述

3.1 錶空間

錶空間是InnoDB 存儲引擎邏輯結構的最高層,所有數據都存放在錶空間中。

如果啟用了innodb_file_per_table 的參數,需要注意的是每張錶的錶空間內存放的只是數據、索引和插入緩沖 Bitmap頁,其他類的數據,如回滾(undo)信息,插人緩沖索引頁、系統事務信息,二次寫緩沖(Double write buffer)等還是存放在原來的共享錶空間內。

3.2 段

錶空間是由各個段組成的,常見的段有數據段、索引段、回滾段等。

3.3 區

區是由連續頁組成的空間,在任何情况下每個區的大小都為1MB。為了保證頁的連續性,InnoDB存儲引擎每次從磁盤一次申請4-5個區。

在默認情况下,InnoDB存儲引擎頁的大小為16KB,即一個區中一-共有64個連續的頁。

3.4 頁

同大多數數據庫一樣,InnoDB有頁(Page)的概念(也可以稱為塊),頁是InnoDB磁盤管理的最小單比特。

在InnoDB存儲引擎中,默認每個頁的大小為16KB。

從InnoDB 1.2.x版本開始,可以通過參數innodb_page_size將頁的大小設置為4K、8K、16K。

常見的頁包括:

  • 數據頁(B-tree Node)
  • undo頁(undo Log Page)
  • 系統頁(System Page)
  • 事務數據頁(Transaction system Page)
  • 插入緩沖比特圖頁(Insert Buffer Bitmap)
  • 插入緩沖空閑列錶頁(Insert Buffer Free List)
  • 未壓縮的二進制大對象頁(Uncompressed BLOB Page)

3.5 行

InnoDB存儲引擎是面向列的(row-oriented),也就說數據是按行進行存放的。

版权声明:本文为[A.iguodala]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210816020516278u.html