mysql 5.7如何平滑升级到8.0_使用mysqlcheck工具与原地升级方案-mysql教程-PHP中文网

mysqlcheck是MySQL 5.7升8.0原地升级前必须执行的表检查与修复工具，需用--check-upgrade等参数检测兼容性、修正大小写及结构问题，并确保停写、锁元数据、清理配置后执行--upgrade=FORCE，再分层验证系统表、权限和SQL行为。

mysql 5.7如何平滑升级到8.0_使用mysqlcheck工具与原地升级方案

mysqlcheck 升级前必须做的表检查与修复

MySQL 5.7 到 8.0 的原地升级（in-place upgrade）不是“直接改版本号就能跑”，mysqlcheck 是唯一能提前暴露不兼容结构的实用工具。跳过这步，升级后 mysqld 很可能无法启动，或查询报错 Table doesn't exist、Incorrect information in file。

关键不是“检查一遍”，而是用对参数：

mysqlcheck -u root -p --all-databases --check-upgrade --fix-db-names --fix-table-names：强制触发 8.0 兼容性检查（--check-upgrade），同时修正库/表名大小写问题（5.7 默认 lower_case_table_names=1，8.0 要求一致）
遇到 error : The table does not comply with the current version of MySQL，说明存在 5.7 特有语法（如 ENUM 默认值为空字符串、TEXT 字段无默认值但建表时写了 DEFAULT ''），必须手动改表结构
对含 JSON 字段的表，mysqlcheck 不报错也不代表安全——8.0 对 JSON 值校验更严，建议用 SELECT * FROM tbl WHERE json_valid(col) = 0; 手动扫一遍

原地升级前必须停掉所有写入并锁定元数据

所谓“原地”，是指复用原有数据目录，不导出导入。但这要求升级过程绝对静默——任何写操作都可能导致 ibdata1 或数据字典损坏，恢复极其困难。

不能只靠 service mysql stop，还要确认：

执行 mysql -e "SHOW PROCESSLIST;"，确保无 Command 为 Query 或 Update 的活跃连接；若有，用 KILL 终止
检查是否有未提交事务：mysql -e "SELECT * FROM information_schema.INNODB_TRX\G"，非空则需人工干预回滚
设置 innodb_fast_shutdown=0 后再停服务，确保 ib_logfile* 完全刷盘，否则 8.0 启动时可能拒绝加载旧日志

升级命令与配置文件的关键修改点

MySQL 8.0 的二进制包替换后，不能直接 mysqld --datadir=... 启动。必须按顺序执行：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

先运行升级命令：

mysqld --upgrade=FORCE --datadir=/var/lib/mysql --basedir=/usr/local/mysql-8.0

这个命令会自动调用 mysql_upgrade（已弃用）的等效逻辑，重建系统表、更新数据字典。常见失败原因：

Can't find file: './mysql/plugin.frm'：说明 5.7 的 mysql.plugin 表仍是 MyISAM 引擎，8.0 已移除支持，需在 5.7 下先执行 ALTER TABLE mysql.plugin ENGINE=InnoDB;
配置文件中保留 query_cache_type=1 或 explicit_defaults_for_timestamp=OFF，会导致启动失败，必须删掉或改为 ON
lower_case_table_names 值不能从 1 改为 0（反之亦然），否则 8.0 拒绝启动，且不可逆

升级后验证哪些指标才算真正成功

看到 mysqld 进程起来不等于升级完成。真实可用要验证三层：

系统表层面：SELECT COUNT(*) FROM mysql.innodb_table_stats; 返回非 0（5.7 是 innodb_table_stats 表，8.0 是 mysql.innodb_table_stats 视图，为空说明字典没刷进去）
权限体系：SELECT user,host,plugin FROM mysql.user WHERE plugin='caching_sha2_password'; —— 8.0 默认认证插件变了，老客户端连不上就卡在这
业务查询层面：重点跑含 GROUP BY、ORDER BY 和子查询的 SQL，8.0 严格了 ONLY_FULL_GROUP_BY 模式，默认开启，很多 5.7 能跑的语句会直接报错

最易被忽略的是字符集继承问题：即使配置了 character-set-server=utf8mb4，已有表的 COLLATION 仍为 utf8mb4_general_ci，而 8.0 推荐 utf8mb4_0900_as_cs，不显式 ALTER TABLE 就不会变，后续排序、去重行为可能和之前不一致。