que*_*fla 3 mysql innodb myisam
在我目前使用的 MyISAM 中，数据库非常小，并保留了几个星期，之后它们会被删除并完全用干净的石板重建。该脚本使用 MYISAM 表，除了在最新的 MYSQL 版本中缺乏支持之外，我从来没有遇到过它们工作方式的问题。
更改为 INNODB 是一件耗时且收益为零的事情。但是，我担心最终可能会出现旧 MySQL 版本不可用或某些其他进程强制迁移的情况。
我的问题是：有谁知道从 MyISAM 更改为 MyinnoDB 只是为了跟上 MySQL 的具体原因。
如果我可以继续使用适合我自己的特定用途的东西，那么当有更紧迫的问题需要注意但现在有问题时，我认为没有理由担心测试和可能的错误。MyISAM 目前没有问题。
有很多充分的理由迁移到 InnoDB。
MyISAM 没有崩溃恢复机制。断电可能会使您的桌子无用。它们可能会被损坏（我已经多次看到这种情况发生）并且您可能能够挽救数据——或者您可能无法挽救数据（我也多次目睹了这一点）。使用 InnoDB，您拥有崩溃恢复机制。
MyISAM 没有“热备份”，文件系统/lvm/磁盘快照可能除外，它需要您将所有表刷新到磁盘。你说你的数据库非常小，所以这可能对你没有太大的吸引力；但是对于较大的数据集，将整个数据库刷新到磁盘所需的时间可能会很长。您有多种热备份 InnoDB 数据库的方法。
MyISAM 的索引写入性能很差。由于缺乏崩溃恢复机制，对 idnex 页面的任何写入都会立即刷新到磁盘。我曾经咨询过一家公司，他们在那里密集地写入了这个 MyISAM 表——它在磁盘上太难了，他们不得不把它放在自己的服务器上。更改为 InnoDB 和 Voila！一切都很轻松：事务日志会为您处理所有这些。
MyISAM 在高并发应用程序上表现很差。您不能同时从两个连接写入同一个表。例如，这会很快导致交通繁忙的站点出现瓶颈。
同样，一旦您获得了对表的写锁，其他人就无法从中读取（除了特定 INSERT 类型的小例外）。使用 InnoDB，您可以进行并发写入和非阻塞读取。
MyISAM 几乎没有任何类型的开发。我不记得 Oracle 或其他任何人的任何博客文章说“我们刚刚改进了 MyISAM 上的 foobar”。InnoDB 正在密集开发中。您可能会在 InnoDB 中获得新功能和错误修复；不在 MyISAM 中。
以上关闭我的头顶。我敢肯定，一旦我提交，就会弹出更多的理由；但这些提供了对 MyISAM 缺点的总体感觉。
但是 - 你说你的数据库非常小。为什么迁移到 InnoDB 会如此耗时？