mysql版本升级的准备工作与步骤
MySQL不支持跨大版本直接升级，须逐级升级并验证路径；需执行物理备份与冷备份，升级前清理废弃参数、检查SQL兼容性，按停写→升级→验证顺序操作。
确认当前 MySQL 版本及升级路径是否受支持
MySQL 官方不支持跨大版本直接升级（比如 5.7 → 8.0），必须逐级升级，且中间版本需在官方支持的升级路径内。例如从 5.6 升级到 8.0，必须先升到 5.7，再升到 8.0；而 5.7.33 可直接升级到 8.0.33，但不能跳到 8.1（尚未 GA）。
- 运行
SELECT VERSION();查看当前版本 - 查阅 MySQL 官方文档中 “Upgrading MySQL” 章节对应你的源/目标版本组合
- 注意：
8.0.31+默认启用sql_mode=STRICT_TRANS_TABLES，可能使原有宽松 SQL 报错 - 若使用 Percona Server 或 MariaDB，不能直接套用 MySQL 升级流程
备份与测试环境准备不可跳过
升级失败可能导致数据字典损坏或无法启动，生产环境必须有可验证的全量备份。仅靠 mysqldump 不够——它不包含 mysql 系统库的完整权限状态、密码哈希格式变化（如 caching_sha2_password）、或 innodb_system 表空间元数据。
- 执行物理备份：
mysqldump --all-databases --routines --events --triggers > full_backup.sql - 同时做冷备份：停库后复制整个
datadir目录（含ibdata1、ib_logfile*） - 在隔离环境还原备份，用新版本二进制包启动，运行
mysql_upgrade（8.0.16+已弃用，改由mysqld --upgrade=FORCE自动完成） - 用应用真实 SQL 流量回放（如
pt-query-digest --replay）验证兼容性
升级前必须检查的配置与语法变更
MySQL 8.0 移除了大量旧特性，部分配置项失效，SQL 解析更严格。未提前清理会导致启动失败或查询异常。
- 禁用已废弃参数：如
query_c、
ache_type
old_passwords、explicit_defaults_for_timestamp（8.0.2+强制为 ON） - 检查 SQL 中是否含
CREATE TEMPORARY TABLE ... SELECT类语句——8.0.30+要求显式指定引擎，否则报错ERROR 1286 (42000): Unknown storage engine 'TEMPORARY' - 用户认证插件变更：
mysql_native_password仍可用，但新用户默认用caching_sha2_password；客户端若为老版本（如 MySQL 5.7 客户端），需在连接串加?serverVersion=8.0或降级插件 -
information_schema视图结构变化（如PROCESSLIST改为performance_schema.threads），监控脚本需同步更新
执行升级的最小风险操作顺序
线上升级不是替换二进制再启服务那么简单。核心原则是：先停写、再升级、最后验证，且每步留退路。
- 将主库设为只读：
SET GLOBAL read_only = ON;，并确认无活跃写入（查SHOW PROCESSLIST） - 停止应用连接，kill 剩余会话：
KILL QUERY或KILL CONNECTION（避免事务中断导致半提交） - 替换二进制文件后，用新
mysqld启动时加--upgrade=FORCE参数（8.0.16+）或确保mysql_upgrade已运行（5.7→8.0必须跑一次） - 启动后立即检查错误日志：
grep -i "error\|warning" /var/log/mysql/error.log，重点关注InnoDB initialization和Data dictionary upgrade - 验证系统表一致性：
SELECT * FROM mysql.innodb_table_stats LIMIT 1;（若报错说明字典升级失败）
mysqld --basedir=/usr/local/mysql-8.0.33 \
--datadir=/var/lib/mysql \
--upgrade=FORCE \
--user=mysql升级后首次启动耗时较长是正常的——InnoDB 需重建数据字典缓存，performance_schema 表需初始化。别在看到日志卡在 “Starting crash recovery” 时误判为 hang 住。
