迁移后权限全失是因为未导出mysql系统库；须显式用mysqldump导出mysql库并加--skip-lock-tables、--routines、--triggers、--events参数，导入前确认目标实例已初始化，再执行mysql -u root -p mysql < mysql_system.sql。
迁移后权限全没了，不是数据导错了，是 mysql 系统库根本没导——mysqldump --databases 默认只导业务库，mysql.user、mysql.db 这些存权限的表压根不会出现，新实例上只剩 root@localhost 能连，其他用户全报 ERROR 1045 (28000): Access denied 或 ERROR 1141 (42000): There is no such grant defined for user。
导出 mysql 系统库必须显式指定，不能依赖 --all-databases
某些 MySQL 版本（尤其是启用了 skip-show-database 或自定义 secure_file_priv 的环境）下，--all-databases 会跳过 mysql 库，或因权限限制无法读取系统表。最稳的方式是单独 dump：
- 加
--skip-lock-tables：避免锁死mysql.user等核心表导致卡住 - 加
--routines和--triggers：存储过程/函数/触发器的DEFINER权限也存在mysql.proc、mysql.event表里 - 加
--events：事件调度器权限同样在系统库中 - 命令示例：
mysqldump -u root -p --skip-lock-tables --routines --triggers --events mysql > mysql_system.sql
导入前确认目标实例已初始化系统库
刚初始化的 MySQL 实例才有干净的 mysql 系统库。如果目标实例是空目录但没初始化，直接执行 mysql -u root -p mysql 会失败——因为 mysql 数据库本身不存在。
- 检查是否已初始化：
ls /var/lib/mysql/mysql/user.frm或ls /var/lib/mysql/mysql/user.ibd（路径依安装方式而定） - 没初始化？别硬导。要么用
mysqld --initialize初始化，要么改用pt-show-grants补救 - 导入命令必须指定数据库：
mysql -u root -p mysql ，不能写成 <code>mysql -u root -p （后者默认进 <code>test库，权限语句执行失败）
跨大版本（如 5.7 → 8.0）严禁直接导入旧版 mysql 库
mysql 库结构在 5.7 和 8.0 之间有重大变更：字段增删、认证插件从 mysql_native_password 改为 caching_sha2_password、user 表字段类型调整等。硬灌会导致：
ERROR 1067 (42000): Invalid default value for 'password_last_changed'- 权限表损坏，甚至整个实例无法启动
- 用户登录失败且无法修复
- 正确做法：走官方升级路径（
mysql_upgrade或停机升级二进制），或用pt-show-grants生成兼容 SQL
已经跳过系统库？用 pt-show-grants 生成可重放的 GRANT 语句
若迁移已完成、旧库还在，别碰 mysql 文件或手写 INSERT——容易漏字段、配错 host、搞混认证插件。用工具最安全：
- 装 Percona Toolkit：
apt install percona-toolkit（Debian/Ubuntu）或yum install percona-toolkit（RHEL/CentOS） - 从旧库导出：
pt-show-grants --user=root --password=xxx --host=old-host > grants.sql - 该命令自动处理：
host匹配、caching_sha2_password兼容性、CREATE USER+GRANT组合、跳过已删除用户 - 在新库执行：
mysql -u root -p （无需手动 <code>FLUSH PRIVILEGES，pt-show-grants输出含此语句）
最容易被忽略的是 host 字段的语义差异：'user'@'localhost' 和 'user'@'127.0.0.1' 是两个独立账户；localhost 走 Unix socket，不走 TCP，权限记录必须单独存在。迁移后务必核对连接方式与对应 host 值是否匹配。
