MySQL MyISAM数据丢失的可能性?

| 许多站点和脚本仍使用MySQL而不是PostgreSQL。我有几个低优先级的博客,因此我不想迁移到另一个数据库,所以我正在使用MySQL。 问题出在他们的低内存VPS上。这意味着我无法启用InnoDB,因为它仅占用大约80MB的内存。所以我不得不冒险运行MyISAM。 考虑到这一点,我使用MyISAM会遇到什么样的数据丢失?如果有人在保存博客文章时发生断电,我会丢失该文章还是整个数据库? 在这些低端机器上,只要不丢失整个数据库,我可以丢失一些最近的评论或博客文章。     
已邀请:
        您可能会发现以下有关MySQL性能的文章:   对我来说,这不仅与表锁有关。表锁只是MyISAM限制之一,您需要考虑在生产中使用它。尤其是如果您来自“传统”数据库,您可能会因MyISAM行为(以及由此导致的默认MySQL行为)而感到震惊–不当关机会损坏它,如果出现某些错误,它将以部分语句执行失败发现等... http://www.mysqlperformanceblog.com/2006/06/17/using-myisam-in-production/     
        MyISAM不兼容ACID,因此缺乏耐用性。这实际上取决于使用InnoDB或停机造成的更多成本……内存。 MyISAM当然是一个可行的选择,但是您的应用程序需要数据库层提供什么?由于其局限性,使用MyISAM可能会使生活变得更艰难,但在某些情况下MyISAM可能会很好。由于锁定性质,仅使用逻辑mysqldump备份将中断您的服务。如果您使用的是二进制日志记录,则可以备份这些备份,以便为增量备份提供备份,如果MyISAM表中有损坏,可以进行重放以帮助恢复。     
        MySQL手册指出了可能损坏表的事件类型,并且有一篇文章介绍了如何使用myisamchk修复表。您甚至可以发出查询来修复它。
REPAIR TABLE table;
但是,没有有关某些类型的崩溃是否为“无法修复”的信息。即使执行备份,这也是我不允许的数据丢失类型。     
        如果服务器崩溃,您的自动增量主键可能会损坏,因此您的博客帖子ID可能会从122、123、75922371234、75912371235(在123之后服务器崩溃)中跳转。我已经看到了它的发生,而且还不是很漂亮。     
        您总是可以在同一VLAN上获得另一台作为备份从属数据库的主机,这将大大降低风险。我相信您唯一的其他选择是: 为您的服务器获取更多RAM或终止某些服务 查看您的主机是否在VLAN上有任何类型的共享数据库托管,您可以支付少量费用使用。 进行定期备份,并为最坏的情况做好准备。     
        以我的拙见,MyISAM不会造成任何数据丢失。 停电造成数据丢失的风险是因为停电,而不是数据库存储机制。     

要回复问题请先登录注册