1. 程式人生 > >MySQL 8.0儲存引擎解析

MySQL 8.0儲存引擎解析

My SQL 8.0儲存引擎解析

MYISAM 儲存引擎

MyISAM基於舊的(並且不再可用)ISAM儲存引擎,但有許多有用的擴充套件。

這裡寫圖片描述

每個MyISAM表被儲存在磁碟中的兩個檔案中。這些檔案具有以表名開頭的名稱,並有一個擴充套件來指示檔案型別。資料檔案具有.MyDD(MyDATA)副檔名。索引檔案具有.MyI(MyIndex)副檔名。表定義儲存在MySQL資料字典中。

MyISAM表具有以下特徵

  • 所有資料值都先以低位元組儲存。這使得資料機和作業系統獨立。對二進位制可移植性的唯一要求是機器使用兩個補足符號整數和IEEE浮點格式。這些要求在主流機器中被廣泛使用。二進位制相容性可能不適用於嵌入式系統,有時會有特殊的處理器。
  • 儲存資料低位元組沒有明顯的速度損失;錶行中的位元組通常是未對齊的,按順序讀取未對齊的位元組比按相反順序讀取只需要很少的處理。此外,獲取列值的伺服器中的程式碼與其他程式碼相比不是時間上關鍵的。
  • 所有數字鍵值首先儲存在高位元組中,以允許更好的索引壓縮。
  • 支援大檔案的檔案系統和作業系統支援大檔案(高達63位的檔案長度)。
  • MyISAM表中有 (232)2(1.844 e+1)行的限制。
  • 每個MyISAM表的最大索引數是64個。
  • 每個索引的最大列數為16個。
  • 最大金鑰長度為1000位元組。這也可以通過改變原始碼和重新編譯來改變。對於金鑰長度大於250位元組的情況,使用比預設的1024位元組更大的金鑰塊大小。
  • 當按排序順序插入行時(如使用AUTO_INCREMENT列時),索引樹被分割,以便高節點只包含一個鍵。這提高了索引樹中的空間利用率。
  • 支援每個表的一個AutoPype增量列的內部處理。MyISAM自動更新此列以進行插入和更新操作。這使得AutoType列更快(至少10%)。序列頂部的值在被刪除後不會重複使用。(當AUTO_INCREMENT列被定義為多列索引的最後一列時,確實會重用從序列頂部刪除的值。)可以使用ALTER TABLE或myisamchk重置AUTO_INCREMENT值。
  • 當混合刪除與更新和插入時,動態大小行更少碎片化。這是通過自動組合相鄰刪除塊並通過在下一個塊被刪除的情況下擴充套件塊來完成的。
  • MyISAM支援併發插入:如果一個表在資料檔案的中間沒有空閒塊,那麼可以在其他執行緒正在從表中讀取的同時向其中插入新行。空閒塊可能由於刪除行或更新具有比當前內容更多的資料的動態長度行而發生。當所有空閒塊用完(填充)時,將來的插入物再次成為併發。
  • 可以將資料檔案和索引檔案放在不同物理裝置上的不同目錄中,以便使用CREATE TABLE的Data DIRECTORY和INDEX DIRECTORY表選項加快速度。請參閱第131.18節,“建立表語法”。
  • 可以對BLB和文字列進行索引。
  • 索引列中允許NULL值。每個鍵需要0到1個位元組。
  • 每個字元列可以有不同的字符集。
  • MyISAM索引檔案中有一個標誌,指示該表是否正確關閉。如果使用–myisam-.-options選項啟動mysqld,MyISAM表在開啟時自動檢查,如果表沒有正確關閉,則修復。
  • MyiSAMCHK將表標記為檢查,如果您使用-Update狀態選項執行表。MyiSAMCHK——快速檢查只有那些沒有這個標記的表。
  • MyiSAMCHK——分析金鑰的部分以及整個金鑰的儲存統計資訊。
  • MySAMPACK可以打包BLUB和VARCHAR列。

MyISAM還支援以下特徵:

  • 支援一個真正的VARCHAR型別;VARCHAR列以一個或兩個位元組儲存的長度開始。
  • 具有VARCHAR列的表可以具有固定的或動態的行長度。
  • 表中VARCHAR和CHAR列的長度的總和可以達到64KB。
  • 任意長度唯一約束。

InnoDB 儲存引擎

InnoDB是一種通用的儲存引擎,它平衡了高可靠性和高效能。在MySQL 8中,InnoDB是預設的MySQL儲存引擎。預設情況下,在沒有 ENGINE=子句 的情況下發出CREATE TABLE語句將建立一個InnoDB表。

InnoDB引擎提供了對資料庫ACID事務的支援,並且實現了SQL標準的四種隔離級別。該引擎還提供了行級鎖和外來鍵約束,它的設計目標是處理大容量資料庫系統,它本身其實就是基於MySQL後臺的完整資料庫系統,MySQL執行時Innodb會在記憶體中建立緩衝池,用於緩衝資料和索引。但是該引擎不支援FULLTEXT型別的索引,而且它沒有儲存表的行數,當SELECT COUNT(*) FROM TABLE時需要掃描全表。當需要使用資料庫事務時,該引擎當然是首選。由於鎖的粒度更小,寫操作不會鎖定全表,所以在併發較高時,使用Innodb引擎會提升效率。但是使用行級鎖也不是絕對的,如果在執行一個SQL語句時MySQL不能確定要掃描的範圍,InnoDB表同樣會鎖全表。

這裡寫圖片描述

在MySQL 8.0 中 InNoDB的增強資訊,可以訪問下面的URL:

兩種引擎的選擇

  大尺寸的資料集趨向於選擇InnoDB引擎,因為它支援事務處理和故障恢復。資料庫的大小決定了故障恢復的時間長短,InnoDB可以利用事務日誌進行資料恢復,這會比較快。主鍵查詢在InnoDB引擎下也會相當快,不過需要注意的是如果主鍵太長也會導致效能問題。大批的INSERT語句(在每個INSERT語句中寫入多行,批量插入)在MyISAM下會快一些,但是UPDATE語句在InnoDB下則會更快一些,尤其是在併發量大的時候。

Memory 儲存引擎

記憶體儲存引擎(以前稱為堆)建立具有儲存在記憶體中的內容的專用表。由於資料易受崩潰、硬體問題或電源中斷的影響,因此僅將這些表用作臨時工作區或從其他表中提取的資料的只讀快取。

這裡寫圖片描述

何時使用記憶體或NDB叢集

開發人員希望部署使用MEMORY儲存引擎來處理重要、高可用性或頻繁更新資料的應用程式,應該考慮NDB叢集是否是更好的選擇。記憶體引擎的一個典型用例涉及這些特性:

  • 涉及諸如會話管理或快取等瞬態、非關鍵資料的操作。當MySQL伺服器停止或重新啟動時,記憶體表中的資料將丟失。
  • 在記憶體儲存中用於快速訪問和低延遲。資料卷可以完全儲存在記憶體中,而不會導致作業系統交換虛擬記憶體頁。
  • 只讀或讀取的大部分資料訪問模式(有限的更新)。
  • NDB群集提供了與具有較高效能級別的MEMORY引擎相同的特性,並提供了MEMORY不可用的附加特性:
  • 行級鎖定和多執行緒操作用於客戶端之間的低爭用。
  • 可擴充套件性,甚至包括混合的語句混合。
  • 可選的磁碟備份操作資料永續性。
  • 無共享架構和多主機操作,沒有單一故障點,啟用99.999%的可用性。
  • 跨節點的資料自動分發;應用程式開發人員不需要定製自定義的分割或分割槽解決方案。
  • 對記憶體不支援的可變長度資料型別(包括BLB和文字)的支援。

(完)