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在线升级场景。 检查
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等参数是否适配新版本默认值
