MySQL 8.4 執行個體中，資料表的 .frm 檔案與 InnoDB 資料字典之間的結構描述不符，可能會導致升級至 MySQL 9.0 失敗。此類不符可能是由於 .frm 檔案損毀所致。若要解決此問題，請在再次嘗試升級之前，傾印並還原受影響的資料表。

如果發生問題，例如新的 mysqld 伺服器無法啟動，請確認您沒有前次安裝的舊 my.cnf 檔案。您可以使用 --print-defaults 選項來檢查 (例如，mysqld --print-defaults)。如果此命令顯示的不是程式名稱，則表示您有一個作用中的 my.cnf 檔案會影響伺服器或用戶端運作。

如果在升級後，您遇到已編譯的用戶端程式發生問題，例如 Commands out of sync 或非預期的核心傾印，則可能是您在編譯程式時使用了舊的標頭或程式庫檔案。在此情況下，請檢查 mysql.h 檔案和 libmysqlclient.a 程式庫的日期，以確認它們來自新的 MySQL 發行版本。如果不是，請使用新的標頭和程式庫重新編譯您的程式。如果程式庫主要版本號碼已變更 (例如，從 libmysqlclient.so.20 變更為 libmysqlclient.so.21)，也可能需要重新編譯針對共用用戶端程式庫編譯的程式。

如果您已使用指定的名稱建立可載入函數，並將 MySQL 升級至實作具有相同名稱之新內建函數的版本，則可載入函數會變成無法存取。若要更正此問題，請使用 DROP FUNCTION 來捨棄可載入函數，然後使用 CREATE FUNCTION 來使用其他非衝突的名稱重新建立可載入函數。如果新版本的 MySQL 實作的內建函數與現有的儲存函數名稱相同，情況也是如此。請參閱 第 11.2.5 節，「函數名稱剖析與解析」，以了解描述伺服器如何解譯不同種類函數參考的規則。

如果由於 第 3.6 節，「準備安裝以進行升級」中概述的任何問題而導致升級至 MySQL 9.0 失敗，伺服器會將所有變更還原至資料目錄。在此情況下，請移除所有重做記錄檔，並在現有的資料目錄上重新啟動 MySQL 8.4 伺服器，以解決錯誤。重做記錄檔 (ib_logfile*) 預設位於 MySQL 資料目錄中。在修正錯誤之後，請在再次嘗試升級之前，執行慢速關閉 (透過設定 innodb_fast_shutdown=0)。