SHOW GRANTS 输出需清洗后才能执行：先创建空用户，过滤USAGE行，替换用户名，处理REQUIRE子句，最后追加FLUSH PRIVILEGES;确保权限生效。
SHOW GRANTS 输出不能直接执行，必须清洗后才能用
MySQL 的 SHOW GRANTS FOR 'user'@'host' 返回的是带 GRANT 语句的文本，但包含两个关键干扰项：一是开头有 GRANT USAGE ON *.* TO ...（权限为空时也返回），二是末尾带 REQUIRE NONE 或其他 REQUIRE 子句，而新用户可能还没创建，直接执行会报错 ERROR 1133 (HY000): Can't find any matching row in the user table。
实操建议：
- 先用
CREATE USER 'newuser'@'localhost' IDENTIFIED BY 'pwd';创建空用户（注意 host 要和源用户一致，否则权限不生效） - 过滤掉
USAGE权限行——它不授任何实际权限，且依赖用户已存在，跳过更安全 - 把每条
GRANT ... TO 'olduser'@'host'中的用户名替换成'newuser'@'host'，注意保留引号和 @ 符号位置 - 若原用户有
REQUIRE SSL等认证要求，需确认新用户是否需要继承；如不需要，可删掉整段REQUIRE ...子句
用 shell 脚本拼接 GRANT 语句时，别漏掉 FLUSH PRIVILEGES
MySQL 5.7+ 在多数情况下自动重载权限，但显式执行 FLUSH PRIVILEGES; 是最稳妥的做法，尤其当脚本在不同版本混用或权限表被直连修改过时。
常见错误现象：脚本输出了所有 GRANT 语句并执行成功，但新用户仍无法访问——大概率是没刷权限缓存。
实操建议：
- 在拼接完所有
GRANT语句后，追加一行FLUSH PRIVILEGES; - 避免用
mysql -e "GRANT ..."连续执行多条，容易因单条失败中断；改用mysql 批量导入更可靠 - 若用
sed替换用户名，注意转义单引号：sed "s/'olduser'@'localhost'/'newuser'@'localhost'/g"
源用户权限含数据库级或表级时，目标库/表必须已存在
GRANT SELECT ON mydb.* TO ... 这类语句执行的前提是 mydb 已存在。如果目标环境尚未建库，GRANT 会报错 ERROR 1044 (42000): Access denied for user ... to database 'mydb'，哪怕你是 root。
使用场景：跨环境迁移权限（如从测试库克隆到新部署的预发库）时极易踩坑。
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
实操建议：
- 提前检查源用户所有
GRANT涉及的数据库名、表名，在目标 MySQL 实例中运行SHOW DATABASES;和SHOW TABLES FROM db_name;验证 - 若库不存在，先执行
CREATE DATABASE IF NOT EXISTS mydb;（注意字符集和排序规则是否匹配） - 表级权限（如
GRANT UPDATE ON mydb.mytable TO ...）要求表结构已存在，仅建库不够
MySQL 8.0+ 的角色（ROLE）权限不能靠 SHOW GRANTS 简单复制
如果源用户通过 GRANT role_name TO 'user'@'host'; 获得权限，SHOW GRANTS 只会显示角色授予语句，不会展开角色内部权限。直接复制该语句到新用户，等于只给了角色名，但角色本身可能未在目标实例中创建。
性能与兼容性影响：角色是 MySQL 8.0 引入的特性，5.7 及更早版本不识别 CREATE ROLE，脚本若未判断版本会直接报错。
实操建议：
- 先查源用户是否被赋予角色：
SELECT * FROM mysql.role_edges WHERE TO_HOST = 'host' AND TO_USER = 'user'; - 对每个角色，用
SHOW GRANTS FOR ROLE 'rolename';单独导出其权限，再手动或脚本合并到新用户 - 在目标实例中确认角色是否存在，不存在则先
CREATE ROLE 'rolename';，再GRANT其权限，最后GRANT 'rolename' TO 'newuser'@'host';
脚本拼权限这事看着简单，真正落地时最麻烦的往往不是语法，而是源和目标环境的隐含差异：用户 host 是否精确匹配、数据库是否就位、角色是否同步、SSL/IDENTIFIED WITH 等认证方式是否兼容——这些细节不逐个核对，跑通第一遍之后，总会在某个凌晨三点的生产切换里冒出来。
