必须先显式创建新用户并清洗show grants输出：过滤grant usage行、替换用户名、删除require子句；角色权限需额外查mysql.role_edges并单独grant；目标库表须预先存在。
SHOW GRANTS 输出不能直接执行，必须清洗
执行 SHOW GRANTS FOR 'olduser'@'localhost' 返回的是一段文本，不是可直接运行的 SQL 脚本。常见干扰项包括：
– 开头的 GRANT USAGE ON *.* TO 'olduser'@'localhost'：不授任何实际权限，且依赖用户已存在，新用户还没建，执行必报 ERROR 1133 (HY000): Can't find any matching row in the user table
– 结尾的 REQUIRE SSL 或 REQUIRE NONE：新用户未创建时，这些子句会直接导致语法失败
– 单引号和转义问题：比如 'olduser'@'192.168.1.%' 里的 % 在 shell 脚本里需额外转义，否则替换出错
CREATE USER 必须显式执行，不能靠 GRANT 隐式创建
虽然 GRANT ... TO 'newuser'@'%' 在用户不存在时会自动调用 CREATE USER，但有严重隐患：
– MySQL 8.0+ 默认启用 require_secure_transport=ON，隐式创建的用户无密码或密码强度不足，连接直接被拒
– 隐式创建用的是默认认证插件（如 caching_sha2_password），旧客户端可能无法登录
– 主机名匹配失效：写 'newuser'@'%' 和 'newuser'@'localhost' 是两个独立账号，localhost 走 socket 连接，不匹配 %
稳妥做法是先执行：CREATE USER 'newuser'@'localhost' IDENTIFIED WITH mysql_native_password BY 'StrongPass123!';
注意三点：
– 主机名（@'localhost'）必须和源用户完全一致
– 显式指定 IDENTIFIED WITH 插件，避免兼容性问题
– 密码需满足当前 validate_password 策略，否则 ERROR 1827 (HY000)
角色权限不会出现在 SHOW GRANTS FOR user 里
如果源用户被授予了角色（例如 app_reader），SHOW GRANTS FOR 'olduser'@'%' 的输出里**完全不会包含这条授权语句**。角色关系只存在 mysql.role_edges 表中。
必须额外查并补授权：
– 查角色关系：SELECT TO_USER FROM mysql.role_edges WHERE FROM_USER = 'olduser';
– 对每个结果执行：GRANT 'app_reader' TO 'newuser'@'%';
– 若需设默认角色，再加：SET DEFAULT ROLE 'app_reader' TO 'newuser'@'%';
漏掉这步，新用户看似“权限全”，实际访问任何表都会报 ERROR 1044 (42000): Access denied
目标库/表不存在时 GRANT 会直接失败
GRANT SELECT ON mydb.* TO 'newuser'@'%'; 要求 mydb 必须已存在，否则报 ERROR 1044 (42000): Access denied for user ... to database 'mydb'。表级权限（如 ON mydb.mytable）更严格，要求表结构也得存在。
迁移前必须核验：
– 执行 SHOW DATABASES LIKE 'mydb';，缺失则补：CREATE DATABASE IF NOT EXISTS mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
– 对关键表执行 SHOW TABLES FROM mydb LIKE 'mytable';，缺失需提前同步 schema
– 字符集和排序规则必须与源库一致，否则权限虽生效，但查询可能因隐式转换失败
真正容易被忽略的点不在语法本身，而在主机名、角色、数据库存在性这三个维度的严格一致性——少一个，权限就断在看不见的地方。
