MySQL 5.7中MyISAM和InnoDB存儲引擎之間的當前差異是什么？

Question

我在stackoverflow本身上看到了關於MyISAM vs InnoDB這個主題的很多問題和答案。

但是，所有問題和答案都太舊了，與當前穩定版本的MySQL 5.7.x無關

當MyISAM和InnoDB都必須進行大量開發時。

因此，我需要目前版本為5.7.x的差異

所以，請不要將我的問題標記為重復，有人請解釋這些存儲引擎目前存在的差異以及它們之后的差異。

另外，請說明應該在哪種情況下為表選擇哪個存儲引擎。

屬於同一模式的不同表是否可以具有不同的存儲引擎，即少數表將具有InnoDB，而少數表將具有MyISAM 。

如果是，那么如何在具有MyISAM和InnoDB的表之間執行JOIN查詢？

MySQL是否會從未來的版本中刪除MyISAM存儲引擎？

Answer 1

您對MyISAM一直在接受新開發的假設是不正確的。 MyISAM沒有收到任何重大的新發展。 MySQL顯然正朝着逐步淘汰MyISAM的方向發展，並且不鼓勵使用MyISAM。

甲骨文公司尚未公布任何具體日期或版本，他們將刪除MyISAM。 我的猜測是MyISAM永遠不會被完全刪除，因為有太多網站無法升級，沒有進行昂貴的測試以確保他們的特定應用程序不會通過轉換為InnoDB而遇到任何回歸問題。

但您可能會注意到，在MySQL 5.7手冊中，MyISAM上的部分已被降級為備用存儲引擎 ，這應該是它獲得較少優先級的線索。

在MySQL 5.7中，MyISAM仍然用於某些系統表，如mysql.user ， mysql.db等。但5.6和5.7中引入的新系統表是InnoDB。 所有系統表都是MySQL 8.0中的InnoDB。

MyISAM仍然不支持ACID的任何屬性。 沒有事務，沒有一致性功能，也沒有持久寫入。 請參閱我對MyISAM與InnoDB的回答。

MyISAM仍然不支持外鍵，因為它的價值。 但即使使用InnoDB，我也很少看到使用外鍵的真實制作網站。

MyISAM僅支持表級鎖定（除了附加到表末尾的一些INSERT，如手冊中所述）。

MySQL 5.7支持MyISAM和InnoDB中的全文索引和空間索引 。 這些功能不是繼續使用MyISAM的原因。

像mysqldump這樣的邏輯備份工具和Percona XtraBackup等物理備份工具都無法在不獲取全局鎖的情況下備份MyISAM表。

您詢問是否可以在同一模式中創建具有不同存儲引擎的各種表。 是的，你可以，這與許多MySQL版本一樣。

您詢問是否可以連接不同存儲引擎的表（順便說一下，表不需要在同一個模式中加入）。 是的，你可以加入這樣的表，MySQL負責所有的細節。 這與許多MySQL版本相同。

但是當你這樣做時會出現一些奇怪的情況，就像你在事務中更新MyISAM表和InnoDB表然后回滾一樣？ 將回滾InnoDB表中的更改，但MyISAM表中的更改不會回滾，因此如果您不小心，可能會破壞數據完整性。 這也與許多MySQL版本一樣。

MyISAM比InnoDB有優勢的情況是一個簡短的列表，而且它越來越短。

• MyISAM中的一些表掃描查詢和批量插入更快。 InnoDB在索引搜索方面更勝一籌。

• MyISAM可以使用比存儲在未壓縮的 InnoDB表中的等效數據更少的存儲空間。 您可以使用myisampack進一步壓縮MyISAM表，但這會使MyISAM表成為只讀。

  如今，在事務存儲引擎中緊湊存儲數據還有其他選擇，例如InnoDB表壓縮或MyRocks 。

• SELECT COUNT(*) FROM MyTable查詢（沒有WHERE子句）在MyISAM中非常快，因為在MyISAM元數據中保留了准確的行數。 InnoDB（或其他MVCC實現）不會保持此計數，因為查看表的每個事務可能會“看到”不同的行數。 只有具有表級鎖定且沒有像MyISAM這樣的事務隔離的存儲引擎才能優化這種情況。

• 為另一個鍵列中的每個不同值獨立自動遞增該數字。 同樣，這需要表級鎖定，因此InnoDB不支持它。

   CREATE TABLE MyTable ( group_id INT NOT NULL, seq_id INT NOT NULL AUTO_INCREMENT, PRIMARY KEY (group_id, seq_id) ) ENGINE=MyISAM; 

• 將MyISAM表從服務器移動到服務器仍然很容易，因為.MYD和.MYI文件是自包含的。 您可以使用InnoDB表執行類似操作，但必須使用可傳輸表空間的復雜功能。 但由於其新的數據字典功能，MyISAM的這種易於移動的表質量在MySQL 8.0中不再有效。

• 在某些負載下，MyISAM可能是internal_tmp_disk_storage_engine的更好選擇，默認為MySQL 5.7中的InnoDB。 如果你運行大量在磁盤上創建臨時表的查詢（內存臨時表不會受益），它可能會給InnoDB引擎帶來壓力。 但是你必須要有很高的查詢率，如果你的查詢在磁盤上創建了這么多的臨時表，你應該嘗試以不同的方式優化查詢。

• MyISAM允許您設置多個密​​鑰緩存，並為特定表定義緩存。 但MyISAM密鑰緩存僅適用於索引結構，不適用於數據。

參考文獻：

https://www.percona.com/blog/2016/10/11/mysql-8-0-end-myisam/

https://www.percona.com/blog/2017/12/04/internal-temporary-tables-mysql-5-7/

http://jfg-mysql.blogspot.com/2017/08/why-we-still-need-myisam.html

Answer 2

我有一個關於工作測驗的問題並且做對了:(參考新版本）：

MyISAM和InnoDB是兩種不同的存儲引擎，可以不同方式處理CRUD操作。

• 鎖定：當在MyISAM存儲引擎中對行進行處理時，所有表將被其他會話鎖定，直到提交更改，這與InnoDB不同，后者僅鎖定特定的選定行（/ s）。 鎖定被釋放，直到會話被提交。 鎖定表或行會導致嘗試與同一表或行交互的其他會話暫停，以防止表中的錯誤數據操作。

• 事務：與MyISAM不同，InnoDB支持事務。 事務是對SELECT，INSERT，UPDATE和DELETE等2個或更多命令的集合，直到完成一個操作。

  1. 原子操作：在InnoDB中設置事務並且操作未完成時 - 它會終止所有更改並按原樣恢復數據庫（全部或者沒有），因此，例如，如果在事務中間存在語法代碼/數據類型不匹配中的錯誤或可能中斷命令包以完成其操作的任何內容 - 所有更改都不會應用，感謝事務atomicy。 另一方面，當使用MyISAM存儲工程時，如果一組命令“中斷”（由於任何原因），操作立即停止，受影響的所有表/行/數據將繼續受到影響，這可能會導致損壞數據庫中的數據（......令人頭疼）。

  2. B.在MyISAM上運行操作是在現場設置的，而InnoDB允許您使用“ROLLBACK”來丟棄任何更改，這在運行事務時最有用。

  3. 事務日志：在創建沒有事務日志的事務時，您可以對數據庫中的表應用任何更改，如果表具有聚簇索引（例如），則數據必須在其中搜索確切的位置必須插入，然后才應用更改。 在DB和事務之間存在事務日志的情況下，更改將首先發送到事務日志，並在將更改發送到DB之前在表中設置其順序 - 這將耗時更少。 數據庫保存所有已完成事務的日志，這有助於選擇還原以前進行的任何事務，並恢復所有更改。 當設置為“簡單”恢復模型時 - 事務將從事務日志中刪除，並且無法恢復數據（通常在DEV環境中使用）。 當設置為“完整”恢復模型時，所有事務都被保存並列出，准備恢復 - 這通常用於可能導致性能問題的生產環境 - 因此備份它們並從服務器刪除可能是一種解決方案。 當設置為“批量記錄”恢復模型時，僅為特定的“重要”更改和命令（導入，導出，插入選擇，選擇，重新組織/重建索引）保存事務日志，並且可能會阻止性能問題。

• 外鍵：與InnoDB不同，MyISAM不使用外鍵。 當表列的foregin鍵設置為指向另一個表列時，如果在指向的表上發生任何更新/刪除，它將知道必須在指向它的另一個表上應用更改。 這會在兩個表之間創建某種鏈接並使數據保持同步。 使用FK設置表可能需要更多努力，這可能被視為缺點（？）。

• FULLTEXT索引：InnoDB在以前的版本中不支持FULLTEXT索引--MyISAM支持它。 切換到MyISAM不是最好的解決方案，所以只需將MySQL更新為支持FULLTEXT索引的版本。 FULLTEXT索引可以采用標題，注釋等等文本進行搜索（在這種情況下，這應該是比“LIKE”命令更好的選項）。

• 空間數據類型：僅在InnoDB上受支持。

總而言之，InnoDB在數據處理，有效性和恢復方面通常更可靠。 對於較新版本，InnoDB將支持主要搜索的FULLTEXT索引 - 當使用沒有更新MySQL選項的舊版本時，使用MyISAM將非常棒。