我遇到過這個問題兩三次了。我的一位客戶恢復了備份，但意外地修改了引擎設置。結果是，所有外鍵約束都失去了，應用程序開始顯示奇怪的結果。如何處理意外的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