多年来我一直读到MyISAM是MySQL/MariaDB的首选数据库引擎，当您有大量的读取操作而不是大量的插入/更新/删除时。
我最近有一个20个表中的5个被损坏了，我不能用各种修复方法恢复它们。结果，每个被损坏/死亡的表都是MyISAM。我不记得是否每个MyISAM表都被损坏了。但是，据我所知，没有一个InnoDB表被损坏。
在过去的几天里，我一直在吃/呼吸和睡觉MariaDB，努力恢复和改进我们的数据库基础设施（副本、备份等），我注意到InnoDB现在是MariaDB的默认和首选引擎（并不总是这样）。
我还读到InnoDB表不太可能像我最近做的那样死得很惨。当InnoDB表死了，它们更容易恢复。
话虽如此，我正在认真考虑将我剩下的所有MyISAM表转换为InnoDB。
我的问题是：
1.我应该期待任何东西炸毁一个活的系统，依赖于这些表（网站，移动应用程序后端等），还是更有可能一切都将继续chugging后转换？
1.说到性能，在一个SELECT方面很繁重的系统上，性能可能会变得更好还是更差？为了表的未来稳定性，即使有一个小的性能损失，也可能仍然值得进行转换，我只是想知道我会遇到什么，这样我就可以在需要时增加RAM和CPU资源。
1.转换这些表是否会以任何方式中断或更改复制？
1.最后一个问题......这些天来，我真的有什么好的理由在MyISAM保留我的任何一张table吗？听起来好像没有。
提前感谢您对这些项目的任何帮助。
2条答案
按热度按时间dced5bon1#
是的，它总是在稳定性和性能之间进行权衡。但是如果你正在使用MariaDB，为什么不使用Aria呢？Aria应该给你两个世界最好的东西。
我是否应该期待依赖这些表的活动系统会发生什么情况
是的-您应该始终为从腐败、勒索软件、流星袭击中恢复做好计划。InnoDB可能比MyISAM更有弹性，但它不能解决所有问题。
在一个在SELECT方面很繁重的系统上，它可能会变得更好还是更坏？
嗯......不会更快。性能是否会有明显下降是一个非常复杂的问题，取决于很多很多因素。如果您正在进行导出/导入迁移，那么返回应该很简单。
转换这些表是否会以任何方式中断或更改复制？
仅当您尝试在运行复制的同时执行转换时。
请在迁移之前设置innodb_file_per_table。
r6l8ljro2#
如果重复的损坏不足以促使我们放弃MyISAM，并且更新的基准通常显示InnoDB甚至对于只读表也更快，并且标记对MyISAM的支持并不重要（特别是对于MyISAM和任何“集群”），那么我还能说什么呢？
OTOH，如果您有“巨大”的表，请注意InnoDB占用的磁盘空间是MyISAM占用的2 - 3倍。（Q4）这 * 可能 * 是在MyISAM中保留表的唯一合理理由，至少在您升级磁盘之前是这样。
如果您运行的是“旧”版本，那么某些特性可能会丢失。例如，
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)复制通常会起作用;甚至可以在主服务器和副本服务器上为一个表使用不同的引擎。不过，可能会出现一些问题。请检查
binlog_format。(Q2)CPU资源很少是MySQL/MariaDB应用程序的瓶颈。如果是的话，通常会有一个构建更好的索引和/或重新制定查询的解决方案。
说到这里，要注意InnoDB将PK与数据进行聚类;这会对索引的选择产生一些影响。请特别参阅 Many-to-many。要改进索引，请参阅Index Cookbook
我同意在开始更改之前 * 设置
innodb_file_per_table = ON。