MySQL 升级失败主因是字符集乱码、客户端版本不一致、应用连接参数过时、时区配置错误及流程遗漏五类问题，需逐项排查修复。
MySQL 版本升级看似只是换二进制、启服务，实际常因细节疏漏导致启动失败、连接异常、业务报错甚至数据不可用。核心问题往往集中在字符集、系统变量、时区、驱动兼容和升级流程本身这五个关键环节。
字符集与列注释乱码引发升级中断
大版本升级（如 5.7→8.0）时，列注释中残留 utf8mb3编码 的非法 字节 是高频拦路虎。MySQL 8.0 严格校验注释字符串是否符合 UTF8MB4 规范，若注释含 Windows-1252 或 GBK 残留乱码（如 ‘xB1xB8xD6’），启动升级会直接报MY-013140 错误并中止。
- 先停库，用原版本客户端执行
SHOW CREATE TABLE tblG逐个检查报错表字段注释 - 确认乱码后，用
ALTER TABLE …… MODIFY COLUMN …… COMMENT '新注释'替换为纯 ASCII 或合法 UTF8MB4 中文 - 务必冷备后再重试升级，避免在错误状态下反复启停
客户端与服务端版本不一致
执行 mysql --version 显示旧版，但 SELECT VERSION() 返回新版——这是 只升级了 mysql d 服务，漏掉 mysql 客户端 工具 的典型表现，多见于 YUM/RPM 在线升级场景。
- 检查
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等参数是否适配新版本默认值
