友情提示：此篇文章大約需要閱讀 8分鐘53秒，不足之處請多指教，感謝你的閱讀。訂閱本站
此文章首發於 Debug客棧 ｜https://www.debuginn.cn
對於數據庫這一塊詢問比較多的就是在 MySQL 中怎麼去選擇一種何時當前業務需求的存儲引擎，而 MySQL 中支持的存儲引擎又有很多種，那麼 MySQL 中分別又有那些，怎麼優雅的使用呢？
劃分引擎原因
在文件系統中，MySQL 將每個數據庫（也可以稱之爲 schema ）保存爲數據目錄下的一個子目錄。創建表時，MySQL 會在數據庫子目錄下創建一個和表同名的 .frm 文件保存表的定義。例如創建一個名爲 DebugTable 的表，MySQL 會在 DebugTable.frm 文件中保存該表的定義。
因爲 MySQL 使用文件系統的目錄和文件來保存數據庫和表的定義，大小寫敏感性和具體的平臺密切相關。在 Windows 系統中，大小寫是不敏感的；而在類 Unix 系統中則是敏感的。不同的存儲引擎保存數據和索引的方式是不同的，但表的定義則是在 MySQL 服務層wk統一處理的。
查看支持引擎
想了解 MySQL 中支持的引擎的情況，可以使用如下命令查看：
show engines;
結果如下（MySQL版本：Ver 8.0.19）：
mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| FEDERATED | NO | Federated MySQL storage engine | NULL | NULL | NULL |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
| InnoDB | DEFAULT | Supports transactions, row-level locking, and foreign keys | YES | YES | YES |
| PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO |
| MyISAM | YES | MyISAM storage engine | NO | NO | NO |
| MRG_MYISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
| BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO |
| CSV | YES | CSV storage engine | NO | NO | NO |
| ARCHIVE | YES | Archive storage engine | NO | NO | NO |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)
存儲引擎分類
MySQL 存儲引擎分類有 MyISAM、InnoDB、Memory、Merge等，可以看上面表中列出的支持引擎，但是其中最爲常用的就是 MyISAM 和 InnoDB 兩個引擎，其中針對於以上講到的存儲引擎，如下表進行對比：
| 對比項目 | MyISAM | InnoDB | Memory | Merge |
|---|---|---|---|---|
| 存儲限制 | 256TB | 64TB | RAM 內存表 | / |
| 是否支持事務 | 否 | 是 | 否 | 否 |
| 是否支持全文索引 | 是 | 否 | 否 | 否 |
| 是否支持數索引 | 是 | 是 | 是 | 否 |
| 是否支持哈希索引 | 否 | 否 | 是 | 否 |
| 是否支持數據緩存 | 否 | 是 | 否 | 否 |
| 是否支持外鍵索引 | 否 | 是 | 否 | 否 |
| 備註 | 支持事務，行級鎖定和外鍵 | 指向MyISAM表操作 |
MyISAM 與 InnoDB 區別
兩種類型最主要的差別是InnoDB支持事務處理與外鍵和行級鎖。
- InnoDB 可藉由事務日誌（ Transaction Log ）來恢復程序崩潰（ crash ），或非預期結束所造成的數據錯誤；
而 MyISAM 遇到錯誤，必須完整掃描後才能重建索引，或修正未寫入硬盤的錯誤。 - InnoDB 的修復時間，一般都是固定的，但 MyISAM 的修復時間，則與數據量的多寡成正比。
- 相對而言，隨着數據量的增加，InnoDB 會有較佳的穩定性。
- MyISAM 必須依靠操作系統來管理讀取與寫入的緩存，而 InnoDB 則是有自己的讀寫緩存管理機制。（ InnoDB 不會將被修改的數據頁立即交給操作系統）因此在某些情況下，InnoDB 的數據訪問會比 MyISAM 更有效率。
- InnoDB 目前並不支持 MyISAM 所提供的壓縮與 terse row formats（簡潔的行格式） ，所以對硬盤與高速緩存的使用量較大。
- 當操作完全兼容 ACID（事務）時，雖然 InnoDB 會自動合併數筆連接，但每次有事務產生時，仍至少須寫入硬盤一次，因此對於某些硬盤或磁盤陣列，會造成每秒 200 次的事務處理上限。
若希望達到更高的性能且保持事務的完整性，就必使用磁盤緩存與電池備援。
當然 InnoDB 也提供數種對性能衝擊較低的模式，但相對的也會降低事務的完整性。而MyISAM則無此問題，但這並非因爲它比較先進，這只是因爲它不支持事務。
應用場景
- MyISAM 管理非事務表。它提供高速存儲和檢索，以及全文搜索能力。如果應用中需要執行大量的 SELECT 查詢，那麼 MyISAM 是更好的選擇。
- InnoDB 用於事務處理應用程序，具有衆多特性，包括 ACID 事務支持。如果應用中需要執行大量的 INSERT 或 UPDATE 操作，則應該使用 InnoDB，這樣可以提高多用戶併發操作的性能。