MySQL 5.7升级8.0实战：原地升级全流程与踩坑记录-育师

MySQL 5.7 在 2023 年 10 月正式结束了官方支持，这意味着安全补丁和 bug 修复都已经停更。我这边线上还有几十套 5.7 实例，从年初开始陆续推进升级，最近刚把最后一套核心业务库切到 8.0，整个过程踩了不少坑，也沉淀了一套可以复用的流程。这篇东西就是把这轮升级从评估、备份、原地升级到验证调优的完整过程梳理一遍，给正准备做同样事的同学一个参考。

先说结论：MySQL 8.0 不是 5.7 的简单小版本迭代，它改了数据字典、默认字符集、认证插件、SQL 行为，升级不当轻则应用报错，重则数据不一致。但只要按一套稳妥的流程走，风险完全可控。我这篇主要讲原地升级（in-place upgrade）路径，这也是单实例场景下最省事的方案。

1. 升级前必须想清楚的三件事

1.1 为什么要升级：5.7 停服风险与 8.0 核心红利

很多人对升级的态度是"能用就不动"，但 5.7 停止维护带来的影响是实打实的。官方不再发布安全补丁，一旦出现新的高危漏洞，你的数据库就暴露在风险里。合规审计那边也迟早会问到这个问题，与其被动应对，不如主动规划。

MySQL 8.0 带来的核心变化，我挑几个对业务有实际感知的：

数据字典重构：8.0 用 InnoDB 存储元数据，取代了 5.7 的 .frm 文件和 MyISAM 系统表。字典操作变成事务性的，DDL 崩溃恢复更可靠。
默认字符集变为 utf8mb4：5.7 默认是 utf8mb3（实际就是 utf8），遇到 emoji、生僻字容易出问题。8.0 默认 utf8mb4，配合新的排序规则 utf8mb4_0900_ai_ci，数据存储和排序行为都有改善。
窗口函数和 CTE：这部分对开发同学是重大利好。以前写排名、累计值要绕道临时变量或子查询，8.0 直接ROW_NUMBER()、LAG()就能搞定，SQL 可读性和维护性上了一个台阶。
认证插件改为 caching_sha2_password：安全强度更高，但也带来兼容问题——老版本的 JDBC 驱动、客户端工具连不上，后面我会专门讲这个坑。
原子 DDL：像ALTER TABLE这类操作，要么完整执行要么完全不执行，不会出现 5.7 里 DDL 中途失败留下半成品状态的情况。

还有不可见索引、降序索引、资源组、持久化系统变量等实用特性，这些听起来新鲜，但真正用起来后你会发现 8.0 值得升级。

1.2 升级路径选型：原地升级还是逻辑迁移

升级到 8.0 有两条主流路线，我分别说说适用场景。

原地升级（in-place）：停服，备份，用 8.0 二进制替换 5.7，启动后执行升级检查。优点是快，数据文件不用重新导入，适合单机或主从环境、数据量大的场景。缺点是升级过程需要停机窗口，且一旦执行了升级操作，不能直接回滚到 5.7，必须依赖升级前的全量备份恢复。

逻辑迁移（logical migration）：用mysqldump或 MySQL Shell 的导出导入工具，把数据从 5.7 导出再导入 8.0。优点是可以在新实例上先验证，风险更低；缺点是数据量大的时候耗时很长，几十 GB 可能要跑几个小时甚至一天，而且导入时索引重建很吃资源。

我的建议是：能用原地升级就用原地升级。数据量在 100GB 以内且允许较长停机窗口的，逻辑迁移也可以接受；但如果你的库是几百 GB 甚至上 TB，逻辑迁移的时间成本会让你崩溃。我这次线上最大的实例是 800GB，原地升级加校验总共花了不到 40 分钟停机时间，这个量级用逻辑迁移根本不敢想。

注意：无论走哪条路，升级前必须做全量备份。原地升级后 5.7 的数据文件目录被 8.0 改了，想回退只能靠备份恢复，这没有例外。

2. 升级前的全面体检

2.1 兼容性检查清单

升级前最忌讳直接拿生产库开干。我每次都会先做一轮全面检查，把可能出问题的点提前列出来。

检查项一：版本与系统环境

5.7 必须是较新的小版本，官方要求至少 5.7.24 以上才能原地升级到 8.0。
操作系统是 64 位 Linux，glibc 版本要满足 8.0 的要求。我用的 CentOS 7.9 没问题，如果你还在用 CentOS 6 这类老系统，先换系统再谈升级。
磁盘空间要预留充足。8.0 升级过程中 InnoDB 数据字典重建会消耗额外空间，我一般预留数据文件大小 1.5 倍以上的剩余空间。

检查项二：SQL 兼容性

8.0 对 SQL 行为有一批收严的改动，最典型的是sql_mode。5.7 默认没开ONLY_FULL_GROUP_BY，很多老业务的 GROUP BY 写法是"宽松模式"下的——只 select 没在 GROUP BY 里的列，这种 SQL 在 8.0 默认配置下直接报错。还有NO_AUTO_CREATE_USER在 8.0 里被移除了，GRANT语句里顺手创建用户的写法会失效。

我用官方提供的MySQL Shell 升级检查器（Upgrade Checker Utility）跑了一遍全库 SQL 模式检查，它会扫描所有存储对象的定义，把不兼容的地方列出来。命令很简单：

mysqlsh --uri root@localhost:3306 --js util.checkForServerUpgrade()

这个检查器会输出三类结果：错误（必须修复）、警告（建议修复）、注意（提示信息）。我当时检查出一批问题，后面实战部分会细说。

检查项三：废弃功能和默认值变更

8.0 移除了一些 5.7 里就已经标记废弃的功能，比如：

mysql_native_password插件默认不再启用（但为了兼容还可以手动开启）。
sys库里的部分存储过程和函数有调整。
部分系统变量被移除或改名，比如query_cache_size相关的参数在 8.0 里完全失效。

如果你的 my.cnf 里配置了这些废弃参数，启动 8.0 时进程可能直接起不来，日志里会明确告诉你哪个变量未知。所以升级前要清理一遍配置文件，把废弃参数摘掉。

2.2 备份策略与回滚预案

这一步是底线，不能省。我习惯做三层防护：

全量物理备份：用xtrabackup对 5.7 做一次完整的物理备份，备份文件拷贝到独立存储。原地升级后如果发现问题，用这份备份恢复到 5.7 环境。
逻辑备份：额外跑一份mysqldump，包含所有库、表结构、数据、触发器、存储过程和事件。逻辑备份放在另一台机器上，防止物理备份文件损坏时无路可退。
binlog 归档：确认 binlog 开启且连续，记录下备份点对应的 binlog 文件名和位置。如果升级后需要追数据，可以实现基于时间点的恢复。

备份命令参考：

# 物理备份 xtrabackup --backup --target-dir=/backup/mysql57_full \ --user=backup_user --password=*** --host=localhost # 逻辑备份（含存储过程、触发器、事件） mysqldump --single-transaction --routines --triggers --events \ --all-databases --set-gtid-purged=OFF > /backup/mysql57_all.sql

备份完成后，我还要做一次恢复演练，在测试机上把备份恢复出来，确认数据可用、服务能正常启动。别等到出问题才第一次尝试恢复，那样风险太大了。

回滚预案也要提前写好。原地升级失败时的标准动作是：停掉 8.0 进程，清空数据目录，用 xtrabackup 恢复 5.7 备份，改回原配置文件，启动服务，验证业务。整个回滚流程我建议在测试环境先演练一遍，真正出问题时照着操作手册执行就行，不用临场想。

3. 核心实操：原地升级全流程

3.1 环境准备与二进制替换

这一节我按实际操作的顺序来写。假设你的环境是：Linux + MySQL 5.7.44，数据目录在 /data/mysql，端口 3306。

第一步：停业务、刷脏页、做最终备份

选择业务低谷期，比如凌晨。先把应用流量摘掉（或者只保留只读），然后执行：

SET GLOBAL innodb_buffer_pool_dump_now = ON; SET GLOBAL innodb_buffer_pool_shutdown_now = ON;

这两条命令分别把 buffer pool 里的热数据页 dump 到磁盘，以及在关闭时快速刷新脏页。目的是让停机过程尽量短。接着正常停库：

systemctl stop mysqld # 或者 mysqladmin -uroot -p shutdown

停库后确认进程真的退出了，再做一个快速物理备份，确保有一个"刚刚停服时"的干净状态。

第二步：备份并替换二进制

先记录当前版本和配置：

/usr/local/mysql/bin/mysql --version cat /etc/my.cnf

然后把 5.7 的安装目录改名保留，解压 8.0 的二进制包：

mv /usr/local/mysql /usr/local/mysql_57_bak tar -xzf mysql-8.0.36-linux-glibc2.12-x86_64.tar.xz -C /usr/local mv /usr/local/mysql-8.0.36-linux-glibc2.12-x86_64 /usr/local/mysql

注意数据目录不要动，/data/mysql 下的文件还是 5.7 的格式，8.0 首次启动时会自动升级数据字典。

第三步：清理配置文件

这一步特别容易踩坑。8.0 对不认识的配置项是直接拒绝启动的。我建议把 my.cnf 里这些参数全部删掉或注释：

query_cache_type、query_cache_size（查询缓存已移除）
innodb_file_format（InnoDB 文件格式已统一）
key_buffer_size（仅对 MyISAM 有效，8.0 里系统表不再是 MyISAM）
log_queries_not_using_indexes（已被其他参数替代）

同时把认证相关配置加上，这里有一个兼容性选择。如果业务端的 JDBC 驱动、PHP 扩展、Python 客户端都已经是新版本（支持 caching_sha2_password），那什么都不用做；如果还有些老客户端一时换不掉，我建议在 my.cnf 里临时加一行：

default-authentication-plugin=mysql_native_password

不过要注意，这是临时方案。等所有客户端升级后，还是应该切回默认的 caching_sha2_password。

数据库实例如果有运行专用账号，8.0 有个变化需要注意：mysql系统库的表结构变了，5.7 里手动建的用户账号、授权信息在升级时会自动迁移，但权限粒度更细了。比如SUPER权限在 8.0 里拆成了SYSTEM_USER、SYSTEM_VARIABLES_ADMIN等多个细权限，如果你的监控账号依赖 SUPER 权限做某些操作（比如设置全局变量），升级后可能需要重新授权。这部分我建议在测试环境先验证一遍监控系统的权限是否够用。

3.2 启动升级与系统表处理

第四步：首次启动 8.0

改好配置后，用 8.0 的二进制启动服务：

systemctl start mysqld

或者直接前台启动看日志：

/usr/local/mysql/bin/mysqld --user=mysql --datadir=/data/mysql --console

首次启动时 8.0 会自动检测到旧的 5.7 数据字典，执行升级动作。日志里能看到类似这样的信息：

[Note] [MY-010768] [Server] Upgrading from MySQL 5.7 to MySQL 8.0 [Note] [MY-011066] [Server] Checking for invalid tables ... [Note] [MY-010951] [Server] The upgrade is done successfully

升级过程会重建数据字典、转换系统表、校验所有表的兼容性。数据量大的实例这里会比较慢，我那套 800GB 的库花了大概 15 分钟。这期间日志会频繁输出，千万别中途 kill 进程，宁可等。

第五步：MySQL 8.0 中手动跑升级校验（老方法）

5.7 时代讲升级都要手动执行mysql_upgrade，8.0 之后不需要了——从 8.0.16 开始，升级动作在服务启动时自动完成。不过还是可以手动跑一下确认状态：

/usr/local/mysql/bin/mysql_upgrade --force

这个命令会再次检查所有数据库对象并更新统计信息，跑完会告诉你有没有错误。其实上面日志显示 "upgrade is done successfully" 就说明系统表层面没问题了，不过我还是习惯手动跑一遍，安心。

第六步：重启并确认版本

升级完成后再正常重启一次，确保下次启动也是干净的：

systemctl restart mysqld /usr/local/mysql/bin/mysql -uroot -p -e "SELECT VERSION();"

输出应该是8.0.x，同时检查关键参数：

SHOW VARIABLES LIKE 'default_authentication_plugin'; SHOW VARIABLES LIKE 'character_set_server'; SHOW VARIABLES LIKE 'sql_mode';

这里要核对三件事：认证插件是否符合你预期的兼容方案、字符集是否是 utf8mb4、sql_mode 是否包含 ONLY_FULL_GROUP_BY。

4. 升级后的验证与调优

4.1 数据一致性验证

升级完成不代表结束，数据验证这步我做得非常细。

表结构与对象检查

先确认所有库表都在、行数和升级前一致。我写了个简单的统计脚本，遍历所有库比对：

SELECT table_schema, COUNT(*) FROM information_schema.tables WHERE table_schema NOT IN ('mysql','sys','performance_schema') GROUP BY table_schema;

重点要检查的对象包括：存储过程、触发器、视图、事件、外键约束。这些在 5.7 升级到 8.0 时可能会因为 SQL_MODE 收紧而创建失败，需要用下面的方式逐一确认：

SELECT ROUTINE_NAME, ROUTINE_DEFINITION FROM information_schema.routines WHERE routine_schema = 'your_db';

数据抽样比对

我习惯对几张核心大表做抽样校验，比如取主键范围内的若干条记录，比较升级前后的字段值。如果有测试环境，可以在升级前跑一套完整的集成测试用例，升级后回归一遍，比人工检查高效得多。

字符集问题排查

5.7 的老库常有字符集不统一的问题——库是 utf8mb4，表却是 latin1。8.0 默认字符集是 utf8mb4，但已存在的表不会自动转换。我升级后遇到过一个情况：某张历史表的字段是 latin1，应用端写入中文没事，但读取后转成 UTF-8 出现乱码。排查方式：

SHOW TABLE STATUS FROM your_db LIKE 'your_table';

发现Collation列是latin1_swedish_ci，确认就是它的问题。用ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4处理后恢复正常。这个动作建议在业务低峰期做，因为会重写整张表。

4.2 性能回归测试与参数调整

数据验证通过后，就要考虑性能问题了。8.0 的默认参数和 5.7 差异不小，直接沿用老配置的话，性能可能不升反降。

先说一个最容易踩的坑：buffer pool 预热

由于升级后服务重启过，buffer pool 是冷的。第一次业务请求会明显感觉变慢，这个不算 bug，是缓存冷启动的正常现象。我升级前特意加了innodb_buffer_pool_dump_at_shutdown=ON和innodb_buffer_pool_load_at_startup=ON，重启后 InnoDB 会自动把之前的 buffer pool 内容加载回来，能省掉相当长的预热时间。

8.0 推荐关注的参数

我对照 5.7 到 8.0 的参数变化，整理了一份常用参数对照表：

参数	5.7 典型值	8.0 建议	说明
innodb_buffer_pool_size	物理内存 50%-70%	同左，可适当调大	8.0 的 buffer pool 管理更高效
innodb_buffer_pool_instances	按池大小	默认即可	8.0 自动调整实例数
innodb_flush_log_at_trx_commit	1	1	保持默认，数据安全优先
innodb_log_file_size	256M-1G	8.0 用 innodb_redo_log_capacity	8.0 改用 redo log 容量参数
max_connections	按业务	同左，注意认证开销	caching_sha2_password 握手开销略大
innodb_flush_method	O_DIRECT	O_DIRECT	保持，别乱改

特别要提innodb_log_file_size这个参数，它在 8.0.30 之后被innodb_redo_log_capacity取代，旧参数虽然还能识别但会告警。我在升级后就把 redo log 容量改成了innodb_redo_log_capacity = 8G，从实际效果看，大量写入场景下的 redo log 切换频率明显降低。

跑一遍压测

有条件的话，用sysbench或mysqlslap做一轮基础压测，对比 5.7 和 8.0 的吞吐。我实际测下来的结果：纯读场景 8.0 有 10%-20% 的提升，写场景差异不大，复杂 SQL（多表 JOIN、子查询）因为优化器改进有明显提升。但这只是参考，不同业务负载差异很大，别拿我的数字当你的预期。

慢查询日志排查

升级后一定要开启慢查询日志，跑几天看看有没有新出现的慢 SQL。我这次升级后发现一条以前 20ms 的 SQL 变成 800ms，排查下来是 8.0 优化器对某个 JOIN 选择了不同的执行计划，加了正确的索引后恢复。这类问题在升级后出现的概率不低，提前开启慢查询日志就是给排查留证据。

5. 高频故障与排查实录

5.1 连接报错：认证插件不兼容

这是升级后最常见的坑，没有之一。现象是应用端报：

Authentication plugin 'caching_sha2_password' cannot be loaded

或者 JDBC 报：

Public Key Retrieval is not allowed

原因上面提过：8.0 默认认证插件从mysql_native_password换成了caching_sha2_password，老客户端驱动不认识新插件。

解决方案分两层：

第一层，升级客户端驱动。Java 用 Connector/J 8.0.x，PHP 用 mysqlnd 7.4+，Python 用 mysql-connector-python 8.0.x。驱动升级不需要改代码，只换 jar 或扩展包。

第二层，实在换不了驱动的，把账号改回旧认证方式：

ALTER USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

或者全局默认改成旧插件（前面 my.cnf 里加过了）。我实际遇到的情况是：某套老系统用的是 2016 年的 PHP 驱动，短期没法升级，只能在账号层面暂时用mysql_native_password顶着。等系统改造完再转回来。

注意：caching_sha2_password首次连接时如果是 SSL 加密通道，没问题；如果不是 SSL，客户端必须先做一次 RSA 公钥交换才能完成认证。JDBC 驱动可能需要显式配置allowPublicKeyRetrieval=true，这个配置项在网络不可信环境要慎重，建议配合 SSL 使用。

5.2 SQL 行为变化：GROUP BY 和保留字

GROUP BY 报错

升级后最常见的 SQL 报错是：

ERROR 1055: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column ...

这就是ONLY_FULL_GROUP_BY模式收紧导致的。5.7 里这个模式默认其实是开启的，但很多老实例从 5.6 升上来时保留了宽松配置，业务代码里就累积了一堆不合规的 GROUP BY。

我处理这类问题的原则是：改 SQL，不改全局配置。逐条把 select 的列要么放进 GROUP BY，要么用聚合函数包起来。虽然可以把sql_mode里的ONLY_FULL_GROUP_BY去掉图省事，但那样会让错误的 SQL 一直潜伏，以后换到其他数据库（比如 PostgreSQL）更痛苦。

保留字冲突

8.0 新增了一些保留字，之前字段名不冲突的在升级后反而报错。典型的是groups、rank、window、cume_dist这些窗口函数相关词。解决方案是 SQL 里用反引号包裹，或者干脆改字段名。我这次就中招了一个rank字段，改了应用 SQL 才恢复。

5.3 启动失败与性能回退

启动失败：配置项不认识

现象是systemctl start mysqld后马上失败，看错误日志：

[ERROR] [MY-000077] [Server] Unknown system variable 'query_cache_type'

这个就是配置里还有废弃参数没清干净。我列过一个废弃参数清单，最常踩的是 query_cache 全家桶、老版本的 innodb_file_format。处理办法就是注释掉后重新启动。

性能回退：执行计划变化

升级后慢 SQL 变多了，不一定是参数问题，很可能是优化器的选择变了。8.0 的优化器对 JOIN 顺序、子查询处理、索引选择都有调整。排查步骤：

用EXPLAIN ANALYZE看新的执行计划。
对比 5.7 时期的执行计划（所以我说升级前要保留一份EXPLAIN快照）。
如果是索引选择问题，先优化索引，不要急着加 hint。
实在不行才用 hint 固定执行计划，但要做好注释说明，避免未来换库时踩坑。

5.4 常见问题速查表

我把升级过程中遇到的问题整理成一张速查表，方便大家直接对照：

现象	原因	快速处理
客户端连不上，报 caching_sha2_password 无法加载	客户端驱动过老	升级驱动；或临时改账号认证插件
JDBC 报 Public Key Retrieval is not allowed	未开启 RSA 公钥获取	JDBC URL 加 allowPublicKeyRetrieval=true（配合 SSL）
SELECT 报错 1055	ONLY_FULL_GROUP_BY 生效	改写 SQL，不用全局配置规避
字段名报语法错误	字段名是 8.0 新增保留字	反引号包裹或改名
服务启动失败，Unknown system variable	配置残留废弃参数	删除/注释废弃参数
升级后首次访问慢	buffer pool 冷启动	开启 dump/load buffer pool 参数
部分中文显示乱码	老表还是 latin1 字符集	ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4
存储过程或触发器缺失	sql_mode 变更导致创建失败	检查 information_schema，重新创建并修正定义

这张表建议打印出来贴在工位上，升级期间遇到问题直接查。

6. 几点实战心得

6.1 升级窗口一定要留足余量

我最初给核心库排的停机窗口是 30 分钟，实际用了 40 分钟——多出来的时间是首次启动时数据字典转换比预期慢了些，加上安全起见我多跑了一遍校验。真实生产环境里，磁盘 IO 负载、系统整体状态都会影响升级耗时，窗口至少按预计的 1.5 倍留。

6.2 先升级从库，再切换，再升级主库

如果是主从架构，我强烈建议用这套顺序：先给从库做原地升级，观察几天确认没有报错和数据差异，然后把主从切换，让升级后的 8.0 从库顶上来接写流量，最后再把老主库升级成新的从库。这样全程业务无感，而且每步都可回退。我这次就是按这个思路做的，心理压力小很多。

6.3 不要忽略监控和备份工具链

升级后我发现一个问题：监控用的 Prometheus mysqld_exporter 版本太老，采集 8.0 指标时部分数据为空；备份脚本里用的 xtrabackup 版本也不兼容 8.0，需要升级到 8.0 对应版本。这类工具链问题不影响核心业务，但会让运维陷入"数据裸奔"状态。所以我建议把监控、备份、同步相关的所有周边工具，在升级前就纳入检查清单。