in-place升级生产环境风险极高，不建议直接执行；必须用逻辑升级隔离风险，将问题暴露在测试阶段而非生产库。mysqld --upgrade=FORCE仅补全缺失系统表，不跳过元数据校验；真正跳过需--upgrade=NONE且手动重建mysql系统库；mysqlcheck --check-upgrade是红绿灯，遇孤立.frm、MyISAM分区表或重名自定义表须先修复；配置文件残留废弃参数会导致启动失败；启动成功后须立即验证版本、sql_mode及认证插件。
in-place 升级在生产环境风险极高，**不建议直接执行**。MySQL 8.0 启动时会对系统表、字符集、sql_mode 等做严格校验，5.7 中“能跑”的状态，在 8.0 下大概率启动失败甚至损坏数据目录。
真正可行的路径是：用逻辑升级隔离风险，把问题暴露在测试阶段，而不是凌晨三点的生产库上。
为什么 mysqld --upgrade=FORCE 不等于“跳过校验”
很多人以为加了这个参数就能绕过检查，实际它只是强制补全缺失的系统表，不会跳过元数据一致性校验：
-
--upgrade=FORCE在 8.0.16+ 中仅对“不存在的系统表”生效，已存在的表结构冲突仍会报错 - 真正跳过自动升级必须用
--upgrade=NONE，但前提是mysql系统库已手动清理并重建（比如通过mysqldump --all-databases导出再导入） - 若误用
--upgrade=FORCE启动只读实例或权限受限环境，会直接失败，错误日志里只有模糊的Table 'mysql.component' doesn't exist
mysqlcheck --check-upgrade 报错就停，别硬扛
这个命令不是提示器，而是升级前的“红绿灯”。它明确告诉你哪些对象“requires upgrade”，但前提是环境干净：
- 存在孤立
.frm文件（比如手动删过.ibd却没DROP TABLE）→ 直接中止，必须先修复或删除对应表 - 分区表用了
MyISAM引擎 → 运行SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE = 'MyISAM' AND CREATE_OPTIONS LIKE '%partitioned%'，结果非空就得先ALTER TABLE ... ENGINE=InnoDB -
mysql库下有自定义表名和 8.0 新系统表重名（如roles、role_edges）→ 必须重命名或删掉，否则启动时初始化失败
配置文件里残留废弃参数，mysqld 就起不来
直接覆盖二进制包后，my.cnf 里哪怕只留一个已移除的参数，也会导致启动失败，错误日志里只有 unknown variable 这种模糊提示：
- 必须删掉：
query_cache_type、explicit_defaults_for_timestamp、log_warnings - 软链接切换更安全：解压新包到独立路径（如
/usr/local/mysql-8.0.42），用ln -sf指向新路径，避免硬编码路径污染 - 检查
bin/mysqld的运行时路径：readelf -d bin/mysqld | grep RUNPATH，若含旧路径（如/usr/local/mysql/lib），得用patchelf改或换官方预编译包
启动成功 ≠ 数据库就绪，这三件事必须立刻做
服务进程起来只是第一步，以下验证缺一不可：
-
SELECT VERSION(), @@sql_mode;—— 确认版本是8.0.x，且ONLY_FULL_GROUP_BY在列表中 -
SHOW VARIABLES LIKE 'default_authentication_plugin';—— 若返回caching_sha2_password，而应用用的是 PyMySQL CREATE USER 'app'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; -
SELECT DEFAULT_COLLATION_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME = 'your_db';—— 确认默认校对规则是否为utf8mb4_0900_ai_ci；SHOW CREATE TABLE验证关键表字符集是否已升为utf8mb4
最常被忽略的点是：升级后首次启动时，performance_schema 和 information_schema 的元数据结构已变，但旧应用若缓存了表结构信息（比如 ORM 的 schema cache），可能查不到字段或报错——这没法靠重启解决，必须清空客户端缓存或重启应用进程。
