1. 项目背景与升级动机
去年我们生产环境的MySQL 5.7集群已经运行了三年多，随着业务量增长，性能瓶颈开始显现。特别是当并发查询超过200QPS时，系统响应时间明显变长。经过团队评估，决定升级到MySQL 8.0以获取以下关键改进：
- 原生JSON支持性能提升（实测查询速度提升40%）
- 窗口函数支持复杂分析查询
- 事务性数据字典（DDL操作不再需要长时间锁表）
- 默认字符集改为utf8mb4（完整支持emoji表情存储）
重要提示：生产环境升级前务必在测试环境完整验证，我们就是吃了这个亏。测试环境只跑了基础功能测试，漏掉了几个关键业务场景。
2. 认证插件变更引发的连锁反应
2.1 默认认证机制的变化
MySQL 8.0将默认认证插件从mysql_native_password改为caching_sha2_password。这个改动导致我们所有使用旧版客户端的应用突然无法连接：
sql复制-- 查看当前用户使用的认证插件
SELECT user,host,plugin FROM mysql.user;
-- 临时解决方案（不推荐长期使用）
ALTER USER 'app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';
2.2 客户端兼容性问题
我们的旧版JDBC驱动（5.1.x）不支持新认证协议，表现为连接时报错：
code复制Authentication plugin 'caching_sha2_password' cannot be loaded
最终解决方案：
- 升级所有Java应用连接池到最新版（推荐mysql-connector-java 8.0.28+）
- 在my.cnf中显式配置默认认证插件（需重启）：
ini复制[mysqld]
default_authentication_plugin=mysql_native_password
3. GROUP BY行为的严格模式
3.1 SQL兼容性破坏
MySQL 8.0默认启用ONLY_FULL_GROUP_BY模式，导致我们原有78个包含GROUP BY的查询语句中有23个报错。典型错误示例：
sql复制-- 5.7下能运行，8.0报错
SELECT department, employee_name, COUNT(*)
FROM employees
GROUP BY department;
3.2 修复策略对比
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 修改SQL | 符合标准 | 工作量大 | 核心业务SQL |
| 禁用严格模式 | 快速修复 | 可能隐藏问题 | 临时应急 |
| 添加ANY_VALUE() | 折中方案 | 需逐个修改 | 非关键报表 |
我们最终采用混合方案：
sql复制-- 方案1：完整列出SELECT中的非聚合列
SELECT department, employee_name, COUNT(*)
FROM employees
GROUP BY department, employee_name;
-- 方案3：对不重要的显示字段使用ANY_VALUE
SELECT department, ANY_VALUE(employee_name), COUNT(*)
FROM employees
GROUP BY department;
4. 保留关键字新增导致的DDL失败
4.1 意外冲突案例
升级后执行一个存储过程创建语句失败，因为使用了新增保留字RANK：
sql复制CREATE PROCEDURE calc_rank() -- 报错
BEGIN
DECLARE rank INT; -- rank现在是保留字
...
END;
4.2 完整保留字列表处理
通过以下命令检查所有可能冲突：
sql复制-- 检查表/列名中的保留字
SELECT table_name, column_name
FROM information_schema.columns
WHERE column_name IN ('rank','groups','cube')
AND table_schema = 'your_db';
-- 解决方案：添加反引号转义
ALTER TABLE `user` CHANGE `rank` `user_rank` INT;
5. 性能优化器带来的执行计划变化
5.1 索引失效案例
一个原本运行良好的查询在8.0下突然变慢10倍。通过EXPLAIN发现优化器选择了不同的索引：
sql复制-- 5.7的执行计划（使用索引A）
-- 8.0的执行计划（错误地使用索引B）
-- 解决方案：使用索引提示
SELECT /*+ INDEX(table index_A) */ * FROM table WHERE ...
5.2 优化器配置调整
我们在my.cnf中添加了这些关键参数：
ini复制[mysqld]
optimizer_switch='derived_merge=off' # 解决部分子查询性能退化
range_optimizer_max_mem_size=256000000 # 提高范围查询内存限制
6. 升级后的监控与回滚方案
6.1 关键监控指标
升级后48小时内密切监控：
- 线程池使用率（threads_running）
- 临时表创建数（created_tmp_tables）
- 锁等待时间（innodb_row_lock_waits）
6.2 回滚准备
我们提前准备了完整的回滚方案：
- 使用mysqldump全量备份（虽然慢但是可靠）
- 配置主从复制，将8.0作为5.7的从库运行24小时
- 准备降级脚本处理不兼容的DDL变更
7. 升级操作完整checklist
7.1 预升级检查
- [ ] 运行mysql_upgrade --check命令
- [ ] 检查所有存储引擎是否为InnoDB
- [ ] 备份所有触发器、存储过程
7.2 升级当天操作
bash复制# 推荐使用in-place升级方式
systemctl stop mysql
yum remove mysql-community-server-5.7
yum install mysql-community-server-8.0
mysql_upgrade -u root -p
systemctl start mysql
7.3 验证步骤
- 业务SQL性能对比测试
- 检查所有外键约束状态
- 验证备份恢复流程
整个升级过程我们遇到了17个意外问题，其中5个造成了严重故障。最深刻的教训是：MySQL大版本升级不是简单的软件更新，而是需要当作数据库迁移项目来管理。建议预留至少两周的缓冲时间，并准备详细的回滚方案。