我遇到过这个问题两三次了。我的一位客户恢复了备份，但意外地修改了引擎设置。结果是，所有外键约束都失去了，应用程序开始显示奇怪的结果。如何处理意外的MySQL数据库引擎更改？
第二件事发生在我们的现场制作服务器上。 MySQL停止支持InnoDB并显示错误“不支持的引擎类型”。
我搜索了Google，发现许多类似的查询。我想知道MySQL是否会解决这个问题。是否是转向PostgreSQL的正确时机？为什么我仍然坚持MySQL是因为它拥有广泛的用户群。我对PostgreSQL了解不多。
任何人都可以建议的方式来处理这个MySQL问题或替代？
MySQL能够使用大量不同SQL Modes支配它是多么沉默和宽容与不正确的查询进行配置。
根据我的经验，大多数发行版中的默认配置太过宽容。
你可能想看看改变这些配置选项你注销的MySQL为不是不够扎实DBMS之前。
将其设置为更严格的模式，你可能会开始恢复，给你线索，什么是错的备份转储时发现的错误。
这听起来像一个明确的迹象表明，从备份恢复是不正确测试，这显然需要做的事情。
这就是说，它不是第一次听说这种情况发生的，有时比差了很多成果。不幸的是，AFAIK并不是真正的防止MySQL在表达引擎无法满足请求时“降级”表格的方法。所以你只需要小心并检查恢复的结果。真的，你应该一直在做。
这是MySQL在很多情况下运行的方式（默默地更改表管理器，忽略外键而不是在使用错误的表管理器时抛出“不支持的功能”错误等），并且它不被视为错误。所以如果你确实认为这是一个你不想忍受的bug，那么可能值得考虑切换数据库。
现在，对于实际问题的提示：我已经看到许多站点只是在他们的监控中部署一个检查（例如nagios），验证所有表是InnoDB，如果他们不是将在通用监控系统中发出重要警报。类似这样的事情很可能在您将不良数据导入系统之前就已经为您找到了这个问题。这远非完美，但它让你有机会提前解决问题。
这种操作无能的气味。
你管理你的服务器构建，使其只能恢复到它不会有mysql的配置错误或不适当的版本定义明确的可再现服务器构建。这是管理应用程序的唯一方法。
我会与您的运营团队或您的运营经理说一句话。
您绝对不应该切换到不同的数据库，因为您的操作团队错误。
这个问题并没有太大的意义。当你说“恢复备份”时，你的意思是什么？这是MySQL转储文件还是系统级备份？谁有权访问您的MySQL服务器配置或安装，以及如何更改或更改原因？ – friedo 2009-12-27 10:41:30
Ya它是一个MySQL转储文件，管理员可以访问它。 – RKh 2009-12-27 10:58:28