MYSQL 8.0 Upgrade &Downgrade的几点注意

来源：这里教程网时间：2026-03-01 16:05:53 作者：

Important

Downgrade from MySQL 8.0 to MySQL 5.7, or from a MySQL 8.0 release to a previous MySQL 8.0 release, is not supported. The only supported alternative is to restore a backup taken before upgrading. It is therefore imperative that you back up your data before starting the upgrade process.

Upgrade Paths

Upgrade from MySQL 5.7 to 8.0 is supported. However, upgrade is only supported between General Availability (GA) releases. For MySQL 8.0, it is required that you upgrade from a MySQL 5.7 GA release (5.7.9 or higher). Upgrades from non-GA releases of MySQL 5.7 are not supported.

Upgrading to the latest release is recommended before upgrading to the next version. For example, upgrade to the latest MySQL 5.7 release before upgrading to MySQL 8.0.

Upgrade that skips versions is not supported. For example, upgrading directly from MySQL 5.6 to 8.0 is not supported.

Once a release series reaches General Availability (GA) status, upgrade within the release series (from one GA version to another GA version) is supported.

Some changes to the responsibility for step 2 occurred in MySQL 8.0.16:

Prior to MySQL 8.0.16, mysql_upgrade upgrades the Performance Schema, the INFORMATION_SCHEMA, and the objects described in step 2. The DBA is expected to invoke mysql_upgrade manually after starting the server.

As of MySQL 8.0.16, the server performs all tasks previously handled by mysql_upgrade . Although upgrading remains a two-step operation, the server performs them both, resulting in a simpler process.

Depending on the version of MySQL to which you are upgrading, the instructions in In-Place Upgrade and Logical Upgrade indicate whether the server performs all upgrade tasks or whether you must also invoke mysql_upgrade

When upgrading from MySQL 5.7 to MySQL 8.0, any undo tablespaces that exist in the MySQL 5.7 instance are removed and replaced by two new default undo tablespaces.

Due to a regression introduced in MySQL 8.0.14, in-place upgrade on a case-sensitive file system from MySQL 5.7 or a MySQL 8.0 release prior to MySQL 8.0.14 to MySQL 8.0.16 failed for instances with partitioned tables and [lower_case_table_names=1](https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/server-system-variables.html#sysvar_lower_case_table_names). The failure was caused by a case mismatch issue related to partitioned table file names. The fix that introduced the regression was reverted, which permits upgrades to MySQL 8.0.17 from MySQL 5.7 or MySQL 8.0 releases prior to MySQL 8.0.14 to function as normal. However, the regression is still present in the MySQL 8.0.14, 8.0.15, and 8.0.16 releases.

Changed Server Defaults

Option/Parameter	Old Default	New Default
Server changes
character_set_server	latin1	utf8mb4
collation_server	latin1_swedish_ci	utf8mb4_0900_ai_ci
explicit_defaults_for_timestamp	OFF	ON
optimizer_trace_max_mem_size	16KB	1MB
validate_password_check_user_name	OFF	ON
back_log	-1 (autosize) changed from : back_log = 50 + (max_connections / 5)	-1 (autosize) changed to : back_log = max_connections
max_allowed_packet	4194304 (4MB)	67108864 (64MB)
max_error_count	64	1024
event_scheduler	OFF	ON
table_open_cache	2000	4000
log_error_verbosity	3 (Notes)	2 (Warning)
InnoDB changes
innodb_undo_tablespaces	0	2
innodb_undo_log_truncate	OFF	ON
innodb_flush_method	NULL	fsync (Unix), unbuffered (Windows)
innodb_autoinc_lock_mode	1 (consecutive)	2 (interleaved)
innodb_flush_neighbors	1 (enable)	0 (disable)
innodb_max_dirty_pages_pct_lwm	0 (%)	10 (%)
innodb_max_dirty_pages_pct	75 (%)	90 (%)
Performance Schema changes
performance-schema-instrument='wait/lock/metadata/sql/%=ON'	OFF	ON
performance-schema-instrument='memory/%=COUNTED'	OFF	COUNTED
performance-schema-consumer-events-transactions-current=ON	OFF	ON
performance-schema-consumer-events-transactions-history=ON	OFF	ON
performance-schema-instrument='transaction%=ON'	OFF	ON
Replication changes
log_bin	OFF	ON
server_id	0	1
log-slave-updates	OFF	ON
expire_logs_days	0	30
master-info-repository	FILE	TABLE
relay-log-info-repository	FILE	TABLE
transaction-write-set-extraction	OFF	XXHASH64
slave_rows_search_algorithms	INDEX_SCAN, TABLE_SCAN	INDEX_SCAN, HASH_SCAN
slave_pending_jobs_size_max	16M	128M
gtid_executed_compression_period	1000	0
Group Replication changes
group_replication_autorejoin_tries	0	3
group_replication_exit_state_action	ABORT_SERVER	READ_ONLY
group_replication_member_expel_timeout	0	5

To check for these issues, execute this command:

mysqlcheck -u root -p --all-databases --check-upgrade

If mysqlcheck reports any errors, correct the issues.

Upgrade Troubleshooting

· A schema mismatch in a MySQL 5.7 instance between the .frm file of a table and the InnoDB data dictionary can cause an upgrade to MySQL 8.0 to fail. Such mismatches may be due to .frm file corruption. To address this issue, dump and restore affected tables before attempting the upgrade again.

· If problems occur, such as that the new mysqld server does not start, verify that you do not have an old my.cnf file from your previous installation. You can check this with the --print-defaults option (for example, mysqld --print-defaults ). If this command displays anything other than the program name, you have an active my.cnf file that affects server or client operation.

· If, after an upgrade, you experience problems with compiled client programs, such as Commands out of sync or unexpected core dumps, you probably have used old header or library files when compiling your programs. In this case, check the date for your mysql.h file and libmysqlclient.a library to verify that they are from the new MySQL distribution. If not, recompile your programs with the new headers and libraries. Recompilation might also be necessary for programs compiled against the shared client library if the library major version number has changed (for example, from libmysqlclient.so.20 to libmysqlclient.so.21).

· If you have created a loadable function with a given name and upgrade MySQL to a version that implements a new built-in function with the same name, the loadable function becomes inaccessible. To correct this, use DROP FUNCTION to drop the loadable function, and then use CREATE FUNCTION to re-create the loadable function with a different nonconflicting name. The same is true if the new version of MySQL implements a built-in function with the same name as an existing stored function. See Section 9.2.5, “Function Name Parsing and Resolution” , for the rules describing how the server interprets references to different kinds of functions.

· If upgrade to MySQL 8.0 fails due to any of the issues outlined in Section 2.11.5, “Preparing Your Installation for Upgrade” , the server reverts all changes to the data directory. In this case, remove all redo log files and restart the MySQL 5.7 server on the existing data directory to address the errors. The redo log files (ib_logfile*) reside in the MySQL data directory by default. After the errors are fixed, perform a slow shutdown (by setting innodb_fast_shutdown=0 ) before attempting the upgrade again.

mysqlcheck --repair --databases _db_name

mysqlcheck --repair --all-databases