caching_sha2_password認證插件提供更多的密碼加密方式，并62616964757a686964616fe59b9ee7ad9431333433636131且在加密方面具有更好的表現(xiàn)，目前MySQL?8.0選用caching_sha2_password作為默認的認證插件，MySQL?5.7的認證插件是MySQL_native_password。如果客戶端版本過低，會造成無法識別MySQL?8.0的加密認證方式，最終導致連接問題。

MySQL存儲引擎現(xiàn)在負責提供自己的分區(qū)處理程序，而MySQL服務器不再提供通用分區(qū)支持，InnoDB和NDB是唯一提供MySQL?8.0支持的本地分區(qū)處理程序的存儲引擎。?如果分區(qū)表用的是別的存儲引擎，存儲引擎必須進行修改。要么將其轉(zhuǎn)換為InnoDB或NDB，要么刪除其分區(qū)。通過MySQLdump從5.7獲取的備份文件，在導入到8.0環(huán)境前，需要確保創(chuàng)建分區(qū)表語句中指定的存儲引擎必須支持分區(qū)，否則會報錯。

MySQL?8.0的默認字符集utf8mb4，可能會導致之前數(shù)據(jù)的字符集跟新建對象的字符集不一致，為了避免新舊對象字符集不一致的情況，可以在配置文件將字符集和校驗規(guī)則設置為舊版本的字符集和校驗規(guī)則。

MySQL?8.0啟動使用的lower_case_table_names值必須跟初始化時使用的一致。使用不同的設置重新啟動服務器會引入與標識符的排序和比較方式不一致的問題。

https://dev.mysql.com/doc/refman/8.0/en/server-systemvariables.html#sysvar_lower_case_table_names

要避免MySQL?8.0上的啟動失敗，MySQL配置文件中的sql_mode系統(tǒng)變量不能包含NO_AUTO_CREATE_USER。

從MySQL?5.7.24和MySQL?8.0.13開始，MySQLdump從存儲程序定義中刪除了NO_AUTO_CREATE_USER。必須手動修改使用早期版本的MySQLdump創(chuàng)建的轉(zhuǎn)儲文件，以刪除NO_AUTO_CREATE_USER。

在MySQL?8.0.11中，刪除了這些不推薦使用的兼容性SQL Mode：DB2，MAXDB，MSSQL，MySQL323，MySQL40，ORACLE，POSTGRESQL，NO_FIELD_OPTIONS，NO_KEY_OPTIONS，NO_TABLE_OPTIONS。從5.7到8.0的復制場景中，如果語句使用到廢棄的SQL Mode會導致復制異常。

在執(zhí)行到MySQL?8.0.3或更高版本的in-place升級時，BACKUP_ADMIN權限自動授予具有RELOAD權限的用戶。

本文對MySQL 5.7到MySQL 8.0的升級過程中出現(xiàn)部分易出現(xiàn)問題進行整理：升級對MySQL版本的要求、升級都做了哪些內(nèi)容、數(shù)據(jù)庫升級做了哪些步驟以及注意事項，希望對大家版本升級有幫助。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的mysql5.1升级5.5_mysql数据库迁移，由版本5.1升级至5.5.29，需要注意哪些的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。