多年来我一直读到MyISAM是MySQL/MariaDB的首选数据库引擎，当你有大量的读操作与大量的插入/更新/删除操作时。对于SELECT方面比较重的表，我坚持使用MyISAM。
我最近有20个表中有5个被损坏，我无法使用各种修复方法恢复生命。结果是，每个被损坏/死亡的表都是MyISAM。不记得是否每个MyISAM表都损坏了。但是，据我所知，没有一个InnoDB表被损坏。
在过去的几天里，我一直在吃/呼吸和睡MariaDB，通过恢复和改进我们的数据库基础设施(副本，备份等)，我注意到InnoDB现在是MariaDB的默认和首选引擎(并非总是如此)。
我还读到InnoDB表不太可能像我最近那样死得很惨。当InnoDB表死亡时，它们更容易恢复。
说了这么多，我正在认真考虑将我所有剩下的MyISAM表转换为InnoDB。
我的问题是:
- 我是否应该期望在依赖于这些表(网站，移动应用程序后端等)的实时系统上发生任何事情，或者更有可能在转换后所有事情都会继续发生?
- 当涉及到性能时，在一个重SELECT的系统上，它可能会变得更好还是更差?即使有一个小的性能打击，转换表的未来稳定性可能仍然是值得的，我只是想知道我在做什么，所以我可能会增加RAM和CPU资源，如果需要的话。
- 转换这些表是否会以任何方式破坏或改变复制?
- 最后一个问题……这些天真的有什么好的理由让我在MyISAM中保留我的任何桌子吗?听起来好像没有。
事先感谢您对这些事项的帮助。
是的，它总是在稳定性和性能之间进行权衡。但是，如果你正在使用MariaDB，为什么不使用Aria，它应该给你两全其美?
我是否应该期望在依赖这些表的活动系统上发生任何事情
是的-你应该总是计划从腐败，勒索软件，流星撞击中恢复。InnoDB可能比MyISAM更有弹性，但它并不能解决所有问题。
在一个偏重SELECT的系统上，它会变得更好还是更糟?
嗯…它不会更快。性能是否会明显下降是一个非常复杂的问题，取决于很多很多因素。如果您正在进行导出/导入迁移，那么返回应该是微不足道的。
转换这些表是否会以任何方式破坏或改变复制?
仅当您在运行复制的同时尝试进行转换时。
在迁移前设置innodb_file_per_table
如果重复的损坏不足以激励我们放弃MyISAM，并且更新的基准测试通常显示InnoDB甚至对于只读表也更快，并且对MyISAM的支持并不重要(特别是MyISAM和任何"集群")，那么我能说什么呢?
oh，如果你有"huge"请注意，InnoDB占用的磁盘空间是MyISAM占用的2 -3倍。这个可能是在MyISAM中保留表的唯一站住脚的理由，至少在升级磁盘之前是这样。
如果您正在运行"old"版本，那么某些功能可能会丢失。例如，FULLTEXT和SPATIAL是最近才添加到InnoDB的。
关于转换的更多细节:http://mysql.rjweb.org/doc.php/myisam2innodb并确保更改key_buffer_size(向下)和innodb_buffer_pool_size(向上):http://mysql.rjweb.org/doc.php/memory
(Q3)复制通常会工作;一个表在Primary和Replica上使用不同的引擎也是可以的。不过，可能会有一些小问题。检查binlog_format.
(Q2) CPU资源很少是MySQL/MariaDB应用的瓶颈。当出现这种情况时，通常有一个解决方法，即构建一个更好的索引和/或重新定义查询。
说到这里，请注意InnoDB将PK与数据聚集在一起;这对索引的选择有一定的影响。特别是多对多。要改进索引，请参见索引食谱
我同意在开始更改之前设置innodb_file_per_table = ON。