MySQL 版本迁移时，mysqldump 是否可靠
对于 5.7 → 8.0 或 8.0 → 8.4 这类跨大版本迁移，
mysqldump在多数场景下仍可用，但必须配合显式参数规避默认行为变更。MySQL 8.0+ 默认启用
sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION，而 5.7 的 dump 可能含隐式类型转换或无默认值的
NOT NULL字段，直接导入会报错
ERROR 1364 (HY000): Field doesn't have a default value。
实操建议：
导出时加--skip-strict-mode（仅限 mysqldump 8.0.28+）或手动在目标库临时设
SET sql_mode='';再导入 强制指定字符集：
mysqldump --default-character-set=utf8mb4 -h old_host ...，避免
utf8（即 utf8mb3）被 8.0 拒绝 跳过不兼容对象：用
--ignore-table=db.old_view屏蔽视图、存储过程等，后续单独处理
mysqlpump 与 mysqldump 的关键差异点
mysqlpump是 MySQL 5.7 引入的并行替代工具，但默认行为更“严格”——它会尝试导出
DEFINER子句，若源库用户不存在于目标库，导入时直接失败
ERROR 1449 (HY000): The user specified as a definer ('u'@'%') does not exist；而 mysqldump默认不带
DEFINER（除非加
--dump-definer）。
使用场景判断：
需要并行导出（尤其大库）：用mysqlpump --default-parallelism=4，但务必加
--skip-definer含大量视图/函数：
mysqlpump对
ALGORITHM=TEMPTABLE视图支持更好，
mysqldump可能导出为空 目标库权限受限：
mysqldump --no-create-info+
--no-data分离结构与数据，比
mysqlpump的粒度更可控
MySQL 8.0+ 中不可忽略的兼容性陷阱
从 5.7 升级到 8.0 后，部分语法和元数据格式已废弃。例如：
mysql.user表结构彻底重构，
password字段改为
authentication_string；
GRANT语句不再隐式创建用户，必须显式
CREATE USER。
迁移前必须检查：
执行SELECT User,Host,plugin FROM mysql.user;，确认所有用户 plugin 是
caching_sha2_password还是
mysql_native_password，后者需在目标库重置密码：
ALTER USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd';检查存储过程中的
TYPE=InnoDB（旧写法），8.0 要求改用
ENGINE=InnoDB，否则
mysqldump导出的建表语句会失效 触发器中引用
OLD/
NEW的字段若为保留字（如
rank），8.0 要求反引号包裹，否则导入报错
ERROR 1064
真正需要工具链协同的环节
纯 SQL 导出导入无法解决字符集升级、权限模型变更、JSON 字段校验增强等底层问题。例如：5.7 的
utf8列在 8.0 中会被识别为
utf8mb3，而 8.0.28+ 默认禁用该编码，必须提前执行
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;。
复杂迁移建议分三步走：
结构迁移：用mysqldump --no-data --skip-triggers --skip-routines导出 DDL，人工替换
TYPE=→
ENGINE=、补全
COLLATE数据迁移：用
mysqlpump --compress-output=LZ4加速传输，但导入前先
SET GLOBAL local_infile = ON;并启动客户端时加
--local-infile权限同步：用
SELECT CONCAT('CREATE USER ''',User,'''@''',Host,''' IDENTIFIED WITH ',plugin,' AS ''',authentication_string,''';') FROM mysql.user; 生成用户语句，再手工调整
最易被跳过的一步是统计信息重建——迁移后立即执行
ANALYZE TABLE，否则查询计划可能严重劣化，尤其涉及分区表或隐藏主键场景。
