MySQL資料庫引擎的比較
這是MySQL資料庫管理系統（DBMS）的可用資料庫引擎之間的比較。 資料庫引擎 （或「儲存引擎」）是DBMS用於從資料庫增刪查改（CRUD）資料的底層軟體組件。
| 資料庫引擎 | 開發商 | 許可 | 支援事務 | 積極發展 |
|---|---|---|---|---|
| Archive | 甲骨文公司 | GPL | 否 | 是 |
| Aria | MariaDB | GPL | 否 | 是 |
| Berkeley DB | 甲骨文公司 | APGLv3 | ? | 否 |
| BlitzDB | ? | GPL | 否 | 是 |
| CONNECT | MariaDB | GPL | ? | 是 |
| CSV | 甲骨文公司 | GPL | 否 | 是 |
| DeepSQL | Deep Information Sciences | Custom Proprietary | 是 | 是 |
| Falcon | 甲骨文公司 | GPL | 是 | 否 |
| InfiniDB | Calpont | GPL | 是 | 是 |
| InnoDB | 甲骨文公司 | GPL | 是 | 是 |
| MyISAM | 甲骨文公司 | GPL | 否 | 否 |
| NDB | 甲骨文公司 | GPLv2 | 是 | 是 |
| TokuDB | TokuTek | Modified GPL | 是 | 是 |
| WiredTiger | WiredTiger | GPL | 是 | 是 |
| XtraDB | Percona | GPL | 是 | 是 |
| Federated | 甲骨文公司 | GPL | ? | 否 |
| FederatedX | MariaDB | GPL | ? | 是 |
| CassandraSE | MariaDB | GPL | 否 | 否 |
| sequence | MariaDB | GPL | 是 | 是 |
| mroonga | MariaDB | GPL | ? | 是 |
| SphinxSE | Sphinx Technologies | GPL | 否 | 是 |
| MyRocks | GPLv2 | 是 | 是 | |
| MyMax | CEICOM Solutions | Custom Proprietary | 是 | 是 |
InnoDB和MyISAM之間的比較[編輯]
- InnoDB通過重放其紀錄檔從崩潰或其他意外關閉中恢復。 MyISAM必須完全掃描並修復或重建任何已更新但未完全重新整理到磁碟的索引或可能的表。 由於InnoDB方法大約是固定時間，而MyISAM時間隨著資料檔案的大小而增長，因此隨著資料庫大小的增長，InnoDB提供了更高的可用性。
- 將innodb_flush_log_at_trx_commit設定為1的InnoDB在每次事務後重新整理事務紀錄檔，大大提高了可靠性。[1]MyISAM必須在完全記錄的檔案系統上執行，例如使用data = journal安裝的ext4，以提供與資料檔案損壞相同的彈性。 （可以將紀錄檔放在SSD裝置上以提高MyISAM效能，類似地，InnoDB紀錄檔可以放在非紀錄檔檔案系統上，例如在SSD上執行的ext2，以獲得類似的效能提升。在任何一種情況下都不會犧牲可靠性。）
- InnoDB可以在可靠性較低但在某些情況下具有更高效能的模式下執行。 將innodb_flush_log_at_trx_commit設定為0將切換到在將控制權返回給呼叫方之前未將事務提交到磁碟的模式。 相反，磁碟重新整理發生在計時器上。[1]
- InnoDB會自動將多個並行插入組合在一起並同時將它們重新整理到磁碟。[2]MyISAM依賴於檔案系統塊快取來快取對資料行和索引的讀取，而InnoDB在引擎本身內執行此操作，將行快取與索引快取相結合。[3]
- 如果存在，InnoDB將以主鍵順序儲存行，否則將儲存第一個唯一鍵順序。 如果選擇金鑰以便於常見操作，這可以明顯更快。如果沒有主鍵或唯一金鑰，InnoDB將使用內部生成的唯一整數金鑰，並將以粗略的插入順序物理儲存記錄，如 MyISAM做到了。 或者，可以使用自動增量主鍵欄位來實現相同的效果。
- InnoDB為資料和索引提供可更新的LZW壓縮頁面儲存。 MyISAM壓縮表無法更新。[4]
- 在完全符合ACID標準的模式下執行時，InnoDB必須每次事務至少對磁碟執行一次重新整理，儘管它會將重新整理與多個連接的插入結合起來。 對於典型的硬碟機或陣列，這將限制每秒約200次更新事務。 對於需要更高事務率的應用程式，將需要具有寫入快取和備用電池的磁碟控制器，以保持事務完整性。 InnoDB還提供了幾種減少這種影響的模式，自然會導致事務完整性保證的遺失，儘管仍然保留了比MyISAM更高的可靠性。 MyISAM沒有這種開銷，只是因為它不支援事務。
- MyISAM使用表級鎖定對任何現有行進行更新和刪除，並可選擇附加新行而不是鎖定並將其插入可用空間。 InnoDB使用行級鎖定。 對於經常更新許多行的大型資料庫應用程式，行級鎖定至關重要，因為單個表級鎖定會顯著降低資料庫中的並行性。
- InnoDB和MyISAM都支援全文搜尋，InnoDB在MySQL 5.6.4中獲得全文索引支援[5]，但結果可能會有顯著差異[6]。
參見[編輯]
- ^ 1.0 1.1 MySQL 5.5 Reference Manual - InnoDB Startup Options and System Variables. [2018-12-17]. （原始內容存檔於2019-08-08）.
- ^ MySQL 5.5 Reference Manual - InnoDB Group Commit. [2018-12-17]. （原始內容存檔於2011-11-04）.
- ^ MySQL 5.5 Reference Manual - The InnoDB Storage Engine. [28 May 2015]. （原始內容存檔於2020-01-01）.
- ^ MySQL 5.5 Reference Manual - myisampack — Generate Compressed, Read-Only MyISAM Tables. [2018-12-17]. （原始內容存檔於2019-11-29）.
- ^ Changes in MySQL 5.6.4 (2011-12-20, Milestone 7). Oracle. December 12, 2011 [2018-12-17]. （原始內容存檔於2020-09-21）.
- ^ InnoDB Full-text Search in MySQL 5.6: Part 2, The Queries!. MySQL Performance Blog. March 4, 2013 [2018-12-17]. （原始內容存檔於2014-07-15）.
外部連結[編輯]
- MySQL Documentation on MyISAM Storage Engine（頁面存檔備份，存於網際網路檔案館）
- MyISAM's open files limit and table-cache problem explained（頁面存檔備份，存於網際網路檔案館）
- The article about problems which will occur in using MyISAM（頁面存檔備份，存於網際網路檔案館）
| ||||||||||||||||||||||