服务器运维MySQL升级注意啥

MySQL 升级是高风险操作，核心原则是：先备份、再测试、最后灰度上线。下面按「升级前 → 升级中 → 升级后」给你一份实战 checklist，适用于大多数生产环境。

一、升级前必须确认（非常关键）

1️⃣ 明确升级路径（是否支持直接升级）

常见支持路径：

• 同大版本升级（如 5.7.25 → 5.7.44）✅ 基本无风险
• 跨大版本
  • 5.7 → 8.0 ✅ 官方支持（但必须检查兼容性）
  • 5.6 → 8.0 ❌ 不推荐直接升级，建议先升到 5.7
  • MariaDB → MySQL ❌ 不兼容，不能“升级”

✅ 官方工具：

• mysql_upgrade（5.7 及以前）
• MySQL 8.0 之后：自动升级数据字典

2️⃣ 完整备份（没备份别动）

必须做：

mysqldump -A --single-transaction --routines --triggers --events > full.sql

或使用：

• xtrabackup（物理备份，推荐）
• 云厂商快照（RDS）

⚠️ 升级失败最常见原因：没备份，回滚不了

3️⃣ 检查 SQL 兼容性和废弃特性

重点检查（尤其是 5.7 → 8.0）：

• ❌ ONLY_FULL_GROUP_BY 行为变化
• ❌ sql_mode 差异
• ❌ 废弃函数：JSON_*，PASSWORD()
• ❌ frm 文件机制变化
• ❌ 系统表结构变化

✅ 建议工具：

mysqld --upgrade=CHECK

4️⃣ 检查业务 SQL（非常容易被忽略）

重点：

• SELECT * + GROUP BY
• 隐式类型转换
• 自增 ID 溢出风险
• 时间字段：TIMESTAMP vs DATETIME
• 字符集：utf8 → utf8mb4

✅ 可提前开启慢查询日志 + 通用日志观察

5️⃣ 确认插件、复制、集群

• 主从 / GTID
• MGR（MySQL Group Replication）
• 第三方插件（审计、加密）
• 自定义函数（UDF）

⚠️ 复制环境中：

先升级从库，再升级主库

6️⃣ 测试环境先跑一遍（必须）

测试流程：

1. 用生产数据恢复
2. 完整升级流程跑一遍
3. 业务回归测试
4. 记录升级耗时

二、升级中注意点

✅ 推荐方式（按风险从低到高）

1. 逻辑升级（最安全）
   • mysqldump → 新版本 → 导入
2. 原地升级（常见）
   • 停库 → 替换二进制 → 启动自动升级
3. 主从滚动升级（生产首选）
   • 从库 → 业务切换 → 主库

⚠️ 不建议：

• 多主同时升级
• 没有回滚方案的升级

升级过程关键操作

• 停止写入（或只读）
• 关闭连接
• 记录版本和参数

SELECT VERSION();
SHOW VARIABLES;

三、升级后必须验证

✅ 基础检查

SELECT VERSION();
SHOW PROCESSLIST;
SHOW SLAVE STATUS\G

✅ 数据一致性

• 表数量
• 行数
• checksum（pt-table-checksum）

✅ 性能检查

• QPS / TPS
• 慢查询数量
• 锁等待

⚠️ 8.0 默认参数差异大，可能需要重新调优

四、常见踩坑总结（真实案例）

五、一句话总结

MySQL 升级 = 备份 + 兼容性检查 + 灰度 + 回滚方案

如果你愿意，可以告诉我：

• 当前版本 → 目标版本
• 是否主从 / 单机 / 容器 / 云 RDS

我可以帮你 定制一套升级方案 + 回滚方案 + 检查脚本。