通過使用命令查看mysql存儲引擎

本文主要給大家簡單講講通過使用命令查看mysql存儲引擎，相關專業術語大家可以上網查查或者找一些相關書籍補充一下，這里就不涉獵了，我們就直奔主題吧，希望通過使用命令查看mysql存儲引擎這篇文章可以給大家帶來一些實際幫助。                                                          

SHOW VARIABLES LIKE 'storage_engine';

一、InnoDB存儲引擎

1.InnoDB是事務型數據庫的首選引擎

支持事務安全表（ACID）

事務的ACID屬性：即原子性、一致性、隔離性、持久性

a.原子性：原子性也就是說這組語句要么全部執行，要么全部不執行，如果事務執行到一半出現錯誤，數據庫就要回滾到事務開始執行的地方。

實現：主要是基于MySQ日志系統的redo和undo機制。事務是一組SQL語句，里面有選擇，查詢、刪除等功能。每條語句執行會有一個節點。例如，刪除語句執行后，在事務中有個記錄保存下來，這個記錄中儲存了我們什么時候做了什么事。如果出錯了，就會回滾到原來的位置，redo里面已經存儲了我做過什么事了，然后逆向執行一遍就可以了。

b.一致性：事務開始前和結束后，數據庫的完整性約束沒有被破壞。（eg:比如A向B轉賬，不可能A扣了錢，B卻沒有收到）

c.隔離性：同一時間，只允許一個事務請求同一數據，不同的事務之間彼此沒有任何干擾；

如果不考慮隔離性則會出現幾個問題：

i、臟讀：是指在一個事務處理過程里讀取了另一個未提交的事務中的數據（當一個事務正在多次修改某個數據，而在這個事務中這多次的修改都還未提交，這時一個并發的事務來訪問該數據，就會造成兩個事務得到的數據不一致）；（讀取了另一個事務未提交的臟數據）

ii、不可重復讀：在對于數據庫中的某個數據，一個事務范圍內多次查詢卻返回了不同的數據值，這是由于在查詢間隔，被另一個事務修改并提交了；（讀取了前一個事務提交的數據，查詢的都是同一個數據項）

iii、虛讀（幻讀）：是事務非獨立執行時發生的一種現象（eg:事務T1對一個表中所有的行的某個數據項做了從“1”修改為“2”的操作，這時事務T2又對這個表中插入了一行數據項，而這個數據項的數值還是為“1”并且提交給數據庫。而操作事務T1的用戶如果再查看剛剛修改的數據，會發現還有一行沒有修改，其實這行是從事務T2中添加的，就好像產生幻覺一樣）；（讀取了前一個事務提交的數據，針對一批數據整體）

d.持久性：事務完成后，事務對數據庫的所有更新將被保存到數據庫，不能回滾

2.InnoDB是mySQL默認的存儲引擎

默認的隔離級別是RR，并且在RR的隔離級別下更近一步，通過多版本并發控制（MVCC）解決不可重復讀問題，加上間隙鎖（也就是并發控制）解決幻讀問題。因此InnoDB的RR隔離級別其實實現了串行化級別的效果，而保留了比較好的并發性能。

MySQL數據庫為我們提供的四種隔離級別：

a、Serializable（串行化）：可避免臟讀、不可重復讀、幻讀的發生；

b、Repeatable read（可重復讀）：可避免臟讀、不可重復讀的發生；

c、Read committed（讀已提交）：可避免臟讀的發生；

d、Read uncommitted（讀未提交）：最低級別，任何情況都無法保證；

從a----d隔離級別由高到低，級別越高，執行效率越低

3.InnoDB支持行級鎖。

行級鎖可以最大程度的支持并發，行級鎖是由存儲引擎層實現的。

鎖：鎖的主要作用是管理共享資源的并發訪問，用于實現事務的隔離性

類型：共享鎖（讀鎖）、獨占鎖（寫鎖)

MySQL鎖的力度：表級鎖（開銷小、并發性低），通常在云服務器層實現

行級鎖（開銷大、并發性高），只會在存儲引擎層面進行實現

4、InnoDB是為處理巨大數據量的最大性能設計。

它的CPU效率可能是任何基于磁盤的關系型數據庫引擎所不能匹敵的

5、InnoDB存儲引擎完全與MySQL云服務器整合

InnoDB存儲引擎為在主內存中緩存數據和索引而維持它自己的緩沖池。InnoDB將它的表和索引在一個邏輯表空間中，表空間可以包含數個文件（或原始磁盤文件）；

6、InnoDB支持外鍵完整性約束

存儲表中的數據時，每張表的存儲都按照主鍵順序存放，如果沒有顯示在表定義時指定主鍵。InnoDB會為每一行生成一個6字節的ROWID,并以此作為主鍵

7、InnoDB被用在眾多需要高性能的大型數據庫站點上

8、InnoDB中不保存表的行數（eg:select count(*)from table時，InnoDB需要掃描一遍整個表來計算有多少行）；清空整個表時，InnoDB是一行一行的刪除，效率非常慢；

InnoDB不創建目錄，使用InnoDB時，MySQL將在MySQL數據目錄下創建一個名為ibdata1的10MB大小的自動擴展數據文件，以及兩個名為ib_logfile0和ib_logfile1的5MB大小的日志文件

二、InnoDB引擎的底層實現

InnoDB的存儲文件有兩個，后綴名分別是 .frm和 .idb；其中 .frm是表的定義文件， .idb是表的數據文件。

1、InnoDB引擎采用B+Tree結構來作為索引結構

B-Tree（平衡多路查找樹）：為磁盤等外存儲設備設計的一種平衡查找樹

系統從磁盤讀取數據到內存時是以磁盤塊位基本單位的，位于同一磁盤塊中的數據會被一次性讀取出來，而不是按需讀取。

InnoDB存儲引擎使用頁作為數據讀取單位，頁是其磁盤管理的最小單位，默認page大小是16k.

系統的一個磁盤塊的存儲空間往往沒有那么大，因此InnoDB每次申請磁盤空間時都會是若干地址連續磁盤塊來達到頁的大小16KB。

InnoDB在把磁盤數據讀入到磁盤時會以頁為基本單位，在查詢數據時，如果一個頁中的每條數據都能助于定位數據記錄的位置，這將會減少磁盤I/O的次數，提高查詢效率。

B-Tree結構的數據可以讓系統高效的找到數據所在的磁盤塊

B-Tree中的每個節點根據實際情況可以包含大量的關鍵字信息和分支，例

每個節點占用一個盤塊的磁盤空間，一個節點上有兩個升序排序的關鍵字和三個指向子樹根節點的指針，指針存儲的是子節點所在磁盤塊的地址。

以根節點為例，關鍵字為17和35，P1指針指向的子樹的數據范圍小于17，P2指針指向的子樹的數據范圍為17----35，P3指針指向的子樹的數據范圍大于35；

模擬查找關鍵字29的過程：

a.根據根節點找到磁盤塊1，讀入內存。【磁盤I/O操作第一次】

b.比較關鍵字29在區間（17,35），找到磁盤塊1的指針P2;

c.根據P2指針找到磁盤塊3，讀入內存。【磁盤I/O操作第二次】

d.比較關鍵字29在區間（26,30），找到磁盤塊3的指針P2；

e.根據P2指針找到磁盤塊8，讀入內存。【磁盤I/O操作第三次】

f.在磁盤塊8中的關鍵字列表中找到關鍵字29.

MySQL的InnoDB存儲引擎在設計時是將根節點常駐內存的，因此力求達到樹的深度不超過3，也就是I/O不需要超過三次；

分析上面的結果，發現需要三次磁盤I/O操作，和三次內存查找操作。由于內存中的關鍵字是一個有序表結構，可以利用二分法查找提高效率；而三次磁盤I/O操作時影響整個B-Tree查找效率的決定因素。

B+Tree

B+Tree是在B-Tree基礎上的一種優化，使其更適合實現外存儲索引結構，B-Tree中每個節點中有key，也有data，而每一頁的存儲空間是有限的，如果data數據較大時將會導致每個節點（即一個頁）能存儲的key的數量很小。當存儲的數據量很大時同樣會導致B-Tree的深度較大，增大查詢時的磁盤I/O次數，進而影響查詢效率。

在B+Tree中所有數據記錄節點都是按照鍵值大小順序存放在同一層的葉子節點上，而非葉子節點上只存儲key值信息，這樣可以大大加大每個節點存儲的key值數量，降低B+Tree的高度；

通常在B+Tree上有兩個頭指針，一個指向根節點，另一個指向關鍵字最小的葉子節點，而且所有葉子節點（即數據節點）之間是一種鏈式環結構。

因此可以對B+Tree進行兩種查找運算，一種是對于主鍵的范圍查找和分頁查找，另一種是從根節點開始，進行隨機查找。

InnoDB中的B+Tree

InnoDB是以ID為索引的數據存儲

采用InnoDB引擎的數據存儲文件有兩個，一個定義文件，一個是數據文件。

InnoDB通過B+Tree結構對ID建索引，然后在葉子節點中存儲記錄

若建立索引的字段不是主鍵ID，則對該字段建索引，然后在葉子節點中存儲的是該記錄的主鍵，然后通過主鍵索引找到對應記錄。

通過使用命令查看mysql存儲引擎就先給大家講到這里，對于其它相關問題大家想要了解的可以持續關注我們的行業資訊。我們的板塊內容每天都會捕捉一些行業新聞及專業知識分享給大家的。