MySQL升级迁移可脚本化但不可全自动，需人工判断字符集、SQL模式、废弃语法、权限模型及存储引擎等兼容性问题；mysqldump+mysql是中小规模库最可控的手动迁移方案。
MySQL 升级迁移能自动化，但不能全自动
MySQL 版本升级（如 5.7 → 8.0）或跨主机迁移本身支持脚本化和工具链集成，但关键决策点必须人工介入：比如字符集兼容性、SQL 模式变更、废弃语法检测、权限模型差异（如 mysql.user 表结构变化）、存储引擎限制（MyISAM 在 8.0 中不支持全文索引）。跳过这些判断直接跑自动化脚本，极大概率导致服务启动失败或数据查询异常。
用 mysqldump + mysql 做基础迁移的实操要点
这是最可控、兼容性最好的手动迁移路径，适合中小规模库（innodb_file_per_table=ON 且单表
- 导出前必须加
--single-transaction --routines --triggers --events，否则可能漏触发器或破坏一致性 - MySQL 8.0 默认启用
sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION，导出时建议显式加--set-gtid-purged=OFF（若不用 GTID）并检查dump文件里是否有CREATE FUNCTION调用DEFINER，否则导入会报Access denied; you need (at least one of) the SUPER privilege(s) - 导入前在目标实例执行
SET GLOBAL log_bin_trust_function_creators = 1;，否则带函数的 dump 会失败 - 不要用
source命令导入大文件，改用mysql -u root -p ，避免客户端超时或内存溢出
用 mysqlsh 的 util.checkForServerUpgrade() 预检升级风险
这是 MySQL 8.0+ 官方推荐的升级前必做步骤，比人工扫日志靠谱得多：
- 需在旧版本服务器上安装对应新版的
mysqlsh（例如从 5.7 升 8.0.33，就装 8.0.33 的 mysqlsh） - 运行命令：
mysqlsh --mysql -h localhost -P 3306 -u root -p -e "util.checkForServerUpgrade({targetVersion: '8.0.33', configPath: '/etc/my.cnf'})" - 输出里重点关注
CRITICAL和WARNING条目：比如Table uses old temporal type（需ALTER TABLE ... MODIFY COLUMN修正）、Uses deprecated authentication plugin（要提前改用户认证方式） - 它不会修改任何数据，只读取元数据和配置，可反复执行
真正需要“自动化”的部分其实是验证与回滚准备
升级脚本里最容易被忽略的是验证逻辑和快速回退能力：
- 导出后立即校验：
md5sum backup.sql+mysql -Nse "SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql','information_schema','performance_schema','sys')"对比源库表数量 - 导入后执行简单查询验证：
SELECT 1、SELECT COUNT(*) FROM mysql.user、抽样查一两个业务表的MIN(created_at), MAX(updated_at) - 回滚不是重跑旧脚本，而是提前保留旧
datadir快照（LVM snapshot 或 rsync 备份），并确认my.cnf中socket和port不冲突，避免新旧实例绑同一个端口起不来
自动化的价值不在“一键升级”，而在于把人容易漏掉的验证项、环境依赖、回退路径固化进流程。哪怕只封装成三个 shell 函数 —— precheck、migrate、verify —— 也比全手工强。真正的坑往往藏在 my.cnf 里一行被注释掉的 lower_case_table_names=1，或者某个视图里用了 8.0 才支持的 JSON_TABLE() 函数。
