先说说一个常见的误区：**`SHOW GRANTS` 的输出直接拿来用，一定会报错**。为什么？因为里面藏着两处“杂质”。 MySQL 的 `SHOW GRANTS FOR 'olduser'@'host'` 返回的是 `GRANT` 语句文本，但包含两个关键干扰项：一是开头有 `GRANT USAGE ON *.* TO ...`（权限为空时也会返回），二是末尾带 `REQUIRE NONE` 或其他 `REQUIRE` 子句。而新用户尚未创建，直接执行会报错 `ERROR 1133 (HY000): Can't find any matching row in the user table`。 因此，正确的清洗流程如下： 1. **先创建空用户**：`CREATE USER 'newuser'@'localhost' IDENTIFIED BY 'pwd'`。注意 `host` 必须和源用户完全一致，否则权限无法生效。 2. **过滤 USAGE 行**：直接跳过所有包含 `USAGE` 的行——它不授予任何实际权限，且依赖用户已存在，删掉最安全。 3. **替换用户名**：用 `sed "s/'olduser'@'localhost'/'newuser'@'localhost'/g"` 批量替换，注意单引号和 `@` 符号的位置都要保留。 4. **处理 REQUIRE 子句**：若原用户有 `REQUIRE SSL` 等认证要求，需确认新用户是否需要继承；如果不需要，直接整段 `REQUIRE` 子句删除。 5. **追加刷新权限**：拼接完所有 `GRANT` 语句后，**必须追加 `FLUSH PRIVILEGES;`**。MySQL 5.7+ 虽多数情况下会自动重载，但显式刷新是最稳妥的做法，尤其当脚本在不同版本混用，或者权限表被直连修改过时。

8.0+ 用户创建：必须显式指定认证插件

还有一点，MySQL 8.0 根本不支持 `CREATE USER LIKE` 语法——直接报错 `ERROR 1064 (42000)`。这不是配置问题，而是该语法在 MySQL 中不存在（属于 MariaDB 功能）。正确的做法是：先显式创建用户，并指定认证插件。 * 若源用户使用的是 `caching_sha2_password`（MySQL 8.0 默认），而目标环境需要兼容旧客户端（如 PHP 7.2、某些 Python 驱动），则新用户应创建为 `mysql_native_password`：
`CREATE USER 'newuser'@'%' IDENTIFIED WITH mysql_native_password BY 'p@ssw0rd';` * 若源用户拥有角色（如被授予 `app_reader`），仅靠 `SHOW GRANTS` 无法获取角色信息，必须额外查询 `mysql.role_edges` 并执行：
`GRANT app_reader TO 'newuser'@'%';`
`SET DEFAULT ROLE app_reader TO 'newuser'@'%';`

GRANT 语句执行前，目标库对象必须已存在

`GRANT SELECT ON mydb.* TO 'newuser'@'%'` 这类语句的前提是 `mydb` 已经存在。如果目标实例尚未建库，会报错 `ERROR 1044 (42000): Access denied for user ... to database 'mydb'`，即使你是 `root` 用户。 * 提前检查源用户所有 `GRANT` 涉及的数据库名、表名，在目标 MySQL 实例中运行 `SHOW DATABASES;` 和 `SHOW TABLES FROM db_name;` 进行验证。 * 若库不存在，先执行 `CREATE DATABASE IF NOT EXISTS mydb;`（注意字符集和排序规则是否匹配）。 * 表级权限（如 `GRANT UPDATE ON mydb.mytable TO ...`）要求表结构已存在，否则会报错；不能只靠 `CREATE DATABASE` 解决。

为什么说 mysqldump 导权限表不靠谱

很多人试图用 `mysqldump -u root -p mysql user db tables_priv` 导出系统表再导入，但风险很高：字段结构版本间不兼容、密码哈希格式错配、`plugin` 插件未同步、`account_locked` 状态丢失等问题频发。 * `mysqldump --all-databases` 默认跳过 `mysql` 库，即使加上 `--databases mysql`，也只导出数据，不触发权限重载逻辑。 * 直接插入 `mysql.user` 在 MySQL 8.0+ 上基本不可行，常因字段缺失或哈希不匹配而中断。 * 真正可审计、可验证、跨版本兼容的方式，仍然是基于 `SHOW GRANTS` 生成标准 SQL，人工或脚本清洗后执行。

容易被忽略的细节

host 匹配依赖 DNS 解析行为，且 `CURRENT_USER()` 与 `USER()` 返回值可能不同。迁移后若权限看似生效但连接失败，优先检查 `skip_name_resolve` 配置是否一致，以及客户端实际解析出的 host 是否落在授权范围内。