MySQL MyISAM数据丢失的可能性？

如何解决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不会造成任何数据丢失。 停电造成数据丢失的风险是因为停电，而不是数据库存储机制。