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将非常棒。