一 . 前言

總是看到有說MySQL某個數據引擎哪裡哪裡有問題的 , 讓我一度懷疑我是不是Mysql 用的不對 , 只會用InnoDB 建表 . 看 MyISAM 的表也沒超過10次.

所以我非常好奇 , 資料庫的存儲引擎 , 大家真的在用嗎?

MySQL 官方文檔:: MySQL 5.7 Reference Manual :: 15 Alternative Storage Engines

二. 涉及的引擎

2.1 不同存儲引擎的特性

修改引擎的相關命令

// 查看 MySQL 版本 (不同版本對於存儲引擎的支持不一樣)
SELECT VERSION();

// 查看支持的引擎
show engines;

// 修改引擎類型
alter table table_name engine=innodb;

複製代碼

三. 引擎的選擇

了解存儲引擎的區別只是一方面 , 更重要的是在何種場景下應該選擇哪些存儲引擎. 存儲引擎使用最多的應該是四種 : InnoDB , MyISAM , Archive , Memory .

但是實際上真正可能用的多的 , 只會是 InnoDB 和 MyISAM

3.1 引擎的選擇

MySQL 各個存儲引擎的使用空間可以說越來越小了, 比如 Memory , 鎖是表鎖 , 又不能持久化數據. 也許業務場景中唯一的作用就是節約成本 , 不用搭一套Redis .

但是都上雲了 , MySQL 伺服器內存的開銷 , 相對價格也不會便宜到哪去.

而針對於 csv 引擎 , 其實就是存儲CSV文件, 那麼搞一套OSS系統存這些可能更便宜.

而更有價值的可能就是各種圖引擎或者特殊功能的引擎 , 但是往往都會有更好的替代品.

對於這些引擎總結起來就一句話 : 除非需要用到某些InnoDB 不具備的特性，並且沒有其他辦怯可以替代，否則都應該優先選擇Inno DB 引擎 <高性能MySQL>

那麼剩下的 , 就是 InnoDB 和 MylSAM 了~~~

3.2 InnoDB 和 MylSAM 的選擇

MySQL 的引擎太多了, 用的最多的應該就是 InnoDB 和 MylSAM, 這也是涉及篇幅最大的兩個數據引擎.

兩個存儲引擎的區別很多 , 但是正在的核心集中在以下幾個方面 :

是否支持事務

MyISAM 本身是不支持事務的 ,

事務就很重要了 , 如果業務線比較長 ,而且強制要求數據完整一致. InnoDB.

如果本身就是單次操作或者可以通過 TCC 的方式進行回滾 , 那麼選擇 MyISAM 也不會對業務產生什麼影響.

MVCC

MyISAM 是不支持 MVCC 的 , MVCC 是 多版本並發控制 , 如果對事務接觸比較深 , 就會了解到四種隔離級別. 而 MySQL 的事務隔離級別就是基於 MVCC 進行實現.

外鍵

外鍵通常用來保證數據的完整性 ,A表的欄位是B表的主鍵，就可以為該欄位設置外鍵約束。 InnoDB 支持外鍵而 MyISAM 不支持.

外鍵其實很討厭 , 刪除數據時如果有外鍵關聯 , 會導致數據刪除不掉,處理起來也會非常複雜. 同時由於強調多表關聯 , 也會導致性能較差

但是外鍵好處也很強大 , 保證了數據的一致和完整. 再也不怕用戶未刪除 ,而屬性被刪除的問題.

不過個人接觸的幾個系統裡面就一個使用了外鍵 ,所以這個特性不能影響到引擎的選擇~~

鎖粒度

鎖粒度通常是指行鎖和表鎖. InnoDB 鎖粒度為行鎖 ,而 MyISAM 為表鎖.

行鎖和表鎖不能一概而論 :

表鎖面積更大 , 但是申請鎖只需要進行一次 ,單次鎖的處理時間更短
行鎖面積小 , 但是需要申請多次鎖 , 單次處理的時間更長

四 . 引擎的對比

了解理論還是不夠 , 所以期望能從數據上看一看 , 兩個存儲引擎到底差了多少 . 實際業務中有沒有必要使用特殊的引擎建表

4.1 InnoDB 與 MylSAM 的性能差距

MyISAM 更快的原因

// 索引不同 ：  
- MyISAM 只有三個文件：索引文件，表結構文件，數據文件
- InnerDB 基於 BTree 的索引方法
> 宏觀 : MyISAM 直接加載索引文件到內存中，由於索引文件的數據量更少，相同時間加載的索引數據就更多
> 微觀 ：InnerDB 尋址需要查詢到塊,再在塊中找到對應的行,但是MyISAM查詢數據很快，直接標識的OFFSET地址


// 事務 ：
- InnerDB 處理時需要維護事務,越複雜的場景這種損耗就會越高

// 緩存機制的不同 ：
- MyISAM 使用 KeyCache ，將頻繁訪問的索引塊直接放到內存中 
- InnerDB 使用 BufferPool ，會緩存數據和索引
> 相對而言MyISAM能夠緩存的數據更多，實際操作也能發現，第二次查詢InnerDB需要 10 秒，而MyISAM只用 1 秒

複製代碼

4.2 理解事務

上面列舉了一堆事務和性能什麼什麼的,但是不論用什麼引擎，都需要深入了解性能和事務的直接聯繫。

首先事務的原理是什麼，從單機事務的角度來說，事務主要是基於MySQL來實現，簡單來說就是從 START TRANSACTION 來開啟事務，到 COMMIT 結束事務。

而看似簡單的兩個步驟，整個在InnerDB中的執行過程是很長的。

以 InnerDB 為例，該引擎為事務提供了四種隔離級別： 讀未提交 ， 讀已提交 ， 可重複讀 ， 可串行化。為了實現這四種隔離級別，InnerDB 對數據進行了加鎖， MVCC ， lock in share mode 等操作。

就光加鎖這一項,就限制了並發的能力。而MVCC機制帶來的快照，同樣會對性能有所影響。其他的引擎同理

// PS ： 性能指標是絕對的嗎？ （100萬數據）
- READ_UNCOMMITTED ： 讀未提交 >> 58 秒
- READ_COMMITTED ： 讀已提交 >> 55 秒
- REPEATABLE_READ ： 可重複讀 >> 35 秒
複製代碼

很奇怪不是，為什麼我們看到的越嚴格的隔離級別反而少了時間 :

因為性能和鎖掛鈎 ，而鎖往往只會在複雜的業務場景中才會有衝突，才會存在並發的問題，我這裡就是單純的寫，本身並不會出現什麼鎖的競爭，也就沒什麼事務的問題。

4.3 理解外鍵

InnerDB 的外鍵這東西,用好了妥妥的可靠性小助手,再也不怕某個數據不存在而作一堆查詢和判斷。數據的完備性大大的提升。

但是這功能沒用好，簡直能把人噁心死。外鍵的設計，是需要對系統有很深的理解的，哪些數據應該綁定，哪些數據不應該建立耦合關係很重要。

但是現在的系統設計思路，會考慮邏輯刪除數據，這個時候外鍵的作用就很小了。

而外鍵同樣是會對性能帶來損耗的：

外鍵的目的在於綁定多張表之間的關係，外鍵在進行子表的寫入操作時，是會對主表加共享鎖，而一旦加了鎖，在並發的場景下，就會有性能的問題。

綜合考慮下： 外鍵的功能僅適用於特殊場景下的完整性約束，而在並發的需求下，能不用就不用吧

總結

本著學習的目的了解了這些 , 雖然MySQL 本身還支持很多種其他的引擎 , 但是最好還是不要嘗鮮. 用的時候一時爽 , 回頭上雲或者切庫的時候 , 那怕是後悔的不得了.

一般業務裡面其實基本上都會選用 InnoDB , 極個別場景會選用 MyISAM, 其實其他的引擎都可以用外部組件來解決. Redis ,MongoDB , ES 就是用來解決這些問題的，所以已經沒有什麼理由非要用 MyISAM 了，而其他的引擎，基本上不需要在生產上實踐

而伴隨著分庫分表的流行 , 加上很多公司會選擇把大數據的計算交給大數據部門來處理, 對 MySQL 的壓力是在逐步變小的.

另外需要注意，性能這東西並不是絕對的，這篇文章不好實踐，也不好追代碼，都是看看別人的博客，然後理解吸收後用自己的話表述出來，也不知道是不是真的~~~

看看實踐者的文章》》

-# MyISAM和InnoDB批量插入1萬數據速度比較

附錄 : 各種存儲引擎

InnoDB :

InnoDB 的數據存儲在表空間（ tablespace ）中
InnoDB 採用MVCC 來支持高井發，並且實現了四個標準的隔離級別
InnoDB 表是基於聚簇索引建立的

MylSAM

MyISAM 提供了全文索引、壓縮、空間函數（ GIS ）等，但My ISAM 不支持事務和行級
MyISAM 會將表存儲在兩個文件中：數據文件和索引文件，分別以.MYD 和. MYI 為擴展名
MyISAM 表可以包含動態或者靜態（長度固定）行。
可以使用myisa 1叩a c k 對My ISAM 表進行壓縮（也叫打包pack ）, 壓縮表是不能進行修改的

Archive 引擎

Archive 存儲引擎只支持INSERT 和SELECT 操作 , Archive 引擎會緩存所有的寫並利用zlib 對插入的行進行壓縮 , 磁碟 IO 更少
表適合日誌和數據採集類應用
支持行級鎖和專用的緩衝區，所以可以實現高並發的插入

Blackhole 引擎 (問題太多 , 不推薦)

會丟棄所有插入的數據，不做任何保存。但是伺服器會記錄Blackhole 表的日誌，所以可以用於複製數據到備庫，或者只是簡單地記錄到日誌
在一些特殊的複製架構和日誌審核時發揮作用。

csv 引擎

將普通的csv 文件（逗號分割值的文件）作為MySQL 的表來處理
不支持索引。csv 引擎可以在資料庫運行時拷入或者拷出文件
將 Excel 等電子表格軟體中的數據存儲為csv 文件，然後複製到MySQL 數據目錄下

Federated 引擎

代理引擎 : 會創建一個到遠程MySQL 伺服器的客戶端連接，井將查詢傳輸到遠程伺服器執行，然後提取或者發送需要的數據。

Memory 引擎

如果需要快速地訪問數據，並且這些數據不會被修改，重啟以後丟失也沒有關係，那麼使用Memory 表
Memory 表至少比MyISAM 表要快一個數量級
Memroy 表是表級鎖，因此並發寫入的性能較差
每行長度固定 , 部分內存的搜費

Merge 引擎

Merge 表是由多個My ISAM 表合併而來的虛擬表
可以用於將MySQL 用於日誌或者數據倉庫類應用

原文連結：https://juejin.cn/post/7173296499726483470
來源：稀土掘金

MySQL : 那麼多數據引擎 , 真的有在用嗎