MySQL升级失败主因是字符集乱码、客户端版本不一致、应用连接参数过时、时区配置错误及流程遗漏五类问题，需逐项排查修复。
MySQL版本升级看似只是换二进制、启服务，实际常因细节疏漏导致启动失败、连接异常、业务报错甚至数据不可用。核心问题往往集中在字符集、系统变量、时区、驱动兼容和升级流程本身这五个关键环节。
字符集与列注释乱码引发升级中断
大版本升级（如5.7→8.0）时，列注释中残留utf8mb3编码的非法字节是高频拦路虎。MySQL 8.0严格校验注释字符串是否符合UTF8MB4规范，若注释含Windows-1252或GBK残留乱码（如'\xB1\xB8\xD6'），启动升级会直接报MY-013140错误并中止。
- 先停库，用原版本客户端执行
SHOW CREATE TABLE tbl\G逐个检查报错表字段注释 - 确认乱码后，用
ALTER TABLE ... MODIFY COLUMN ... COMMENT '新注释'替换为纯ASCII或合法UTF8MB4中文 - 务必冷备后再重试升级，避免在错误状态下反复启停
客户端与服务端版本不一致
执行mysql --version显示旧版，但SELECT VERSION()返回新版——这是只升级了mysqld服务，漏掉mysql客户端工具的典型表现，多见于YUM/RPM在线升级场景。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 检查
which mysql路径，确认是否仍指向旧版/usr/bin/mysql - 重新安装对应版本的
mysql-community-client包（非仅server包） - 验证：重启终端后运行
mysql -V与mysql -e "SELECT VERSION();"应完全一致
应用层连接报错：tx_isolation与serverTimezone
升级到8.0后，Java等应用常见两类报错：Unknown system variable 'tx_isolation' 和 server time zone value is unrecognized。
-
tx_isolation在8.0中已废弃，改用transaction_isolation；需更新JDBC URL参数，将tx_isolation=REPEATABLE-READ改为transactionIsolation=TRANSACTION_REPEATABLE_READ - 时区报错主因是系统时区名不被识别（如‘中国标准时间’），应在JDBC URL中显式指定IANA标准时区，例如
serverTimezone=Asia/Shanghai，而非操作系统本地名称 - 同时检查MySQL服务端
time_zone变量是否设为SYSTEM或具体值，避免依赖模糊名称
升级流程遗漏关键检查项
跳过预检或误操作会导致隐性故障。例如未运行mysqlsh --util.checkForServerUpgrade()，可能忽略存储引擎弃用（如MyISAM在8.0中仅限只读）、SQL Mode变更（如ONLY_FULL_GROUP_BY默认启用）等问题。
- 升级前必须用
mysqlsh对应版本执行全量兼容性扫描 - 升级后立即运行
mysql_upgrade（8.0.16起已弃用，改由mysqld自动触发，但仍需确认DD表填充完成） - 检查
error log末尾是否有Finished populating Data Dictionary，而非中途中断 - 切勿复用旧版
my.cnf——尤其注意default-storage-engine、character-set-server等参数是否适配新版本默认值
