是蘇達发动机比数据库引擎InnoDB由于文件系统错误导致数据丢失？
看来 InnoDB 无法用 MySQL 工具修复。
我必须选择我的引擎，由于外键，我选择了 InnoDB，但如果这看起来更安全，我会考虑引擎迁移。
答案1
InnoDB 的后台架构非常精妙
InnoDB架构
如果发生崩溃，InnoDB 具有双写缓冲区和日志文件来支持崩溃恢复机制。MyISAM 没有这样的保护。我在 DBA StackExchange 上写过关于此问题的帖子：
Oct 08, 2012：MYSQL MyISAM数据恢复实现Mar 19, 2012：非常小的 MySQL 表不断崩溃Mar 15, 2012：MySQL 表为何崩溃？如何防止这种情况发生？Feb 16, 2012：MyISAM 表不断崩溃。我有什么选择？
MyISAM 很容易崩溃，因为数据从不缓存在内存中。所有读取和写入都需要从 MyISAM 表文件进行强力 I/O .MYD。这意味着打开的文件句柄完全由操作系统决定。
如果希望 InnoDB 可修复，则需要配置 my.cnf，使 InnoDB 更少地依赖操作系统，而更多地依赖内部架构。请参阅我最近的帖子由于 mysql cpu 使用率高导致平均负载高这样，InnoDB 崩溃恢复就可以更加自我修复。
答案2
我会使用 InnoDB，因为它的每条记录都有锁，而 MyIsam 的每张空表都有锁。此外，正如前面所说，InnoDB 不需要修复工具。此外，InnoDB 引擎可以将表保存在单独的文件中，因此从文件系统崩溃的角度来看它更安全。
答案3
文件系统错误，甚至块级错误，都不是 MyISAM 或 Innodb 实现经过广泛测试或考虑的项目。虽然在写入时可能会发生一些检测，但人们普遍认为，一旦写入时没有返回错误，它就是正确的。校验和存在并在读取时进行检查，但我认为，校验和失败的页面/行上的错误恢复路径尚未得到充分考虑。
我认为针对这种情况（以及其他几种形式的服务器故障）的正确风险缓解策略是在不同文件系统上运行复制从属服务器，并作为 DR 保留二进制日志和逻辑 SQL 快照转储。这样，您就不需要依赖可能能够解决某些形式的数据丢失故障的工具。