最稳妥的mysql权限迁移方式是用pt-show-grants导出标准授权语句，因其可读性强、跨版本兼容且避免直接操作mysql系统表；需人工编辑剔除开发账号、调整host网段、补全require ssl，并验证目标库用户存在性、密码插件及最小权限匹配。
不能直接复制 mysql 库文件或执行 GRANT ALL PRIVILEGES ON *.*，生产环境必须按最小权限原则重建权限，且需验证 host 匹配、密码强度和 SSL 要求。
用 pt-show-grants 导出标准授权语句（推荐）
这是最安全、可读性强、跨版本兼容的方式。它把权限转成人类可读的 GRANT 语句，避免直接操作系统表带来的风险。
- 在源库（开发环境）安装并运行：
pt-show-grants --user=root --password=xxx --host=127.0.0.1 > grants_dev.sql - 手动编辑
grants_dev.sql：删掉root、测试账号、'%'@'%'类宽泛 host；将'dev_user'@'localhost'改为'app_user'@'10.20.30.%'等生产网段 - 检查是否包含
REQUIRE SSL—— 生产环境应强制启用，否则需补上 - 目标库导入前，先用
mysql -u root -p -e "SELECT user,host FROM mysql.user;"确认无重名用户，避免CREATE USER报错
mysqldump 导出权限表后需手动清理
直接导出 mysql.user 等表看似简单，但极易带入开发环境脏数据：空密码、通配 host、过期账号、未加密字段等。
- 导出命令必须限定表：
mysqldump -u root -p --databases mysql --tables user db tables_priv columns_priv procs_priv > priv_dump.sql - 导入前必须用文本编辑器或
sed删除所有含'root'、'test'、'%'的行（除非明确允许） -
user表中的plugin字段在 MySQL 8.0+ 默认是caching_sha2_password，若目标库是 5.7，需改为mysql_native_password，否则连接失败 - 导入后务必执行
FLUSH PRIVILEGES;—— 因为是直接写系统表，不会自动生效
host 匹配错误导致权限不生效（高频坑）
MySQL 权限匹配是“最长 host 前缀优先”，'app'@'10.20.%' 和 'app'@'10.20.30.45' 是两个独立条目，后者优先级更高。生产环境中常因 IP 段写错或 DNS 解析差异导致权限失效。
- 确认应用实际连接来源：
SELECT host FROM information_schema.processlist WHERE user='app_user'; - 检查权限是否命中：
SHOW GRANTS FOR 'app_user'@'10.20.30.45';（注意要填真实 IP，不是通配符） - 禁止使用
'app_user'@'%'，哪怕加了REQUIRE SSL—— 攻击面仍过大；改用最小化网段如'app_user'@'10.20.30.%' - 若应用走代理或容器网络，host 可能是内网 VIP 或 Pod IP，需提前采集真实值再授权
密码策略与认证插件不一致
开发库可能用 mysql_native_password + 简单密码，而生产库启用了强密码策略或双因素认证插件，直接迁移会导致连接拒绝。
- 检查源库密码哈希方式：
SELECT user, host, plugin FROM mysql.user WHERE user='app_user'; - 目标库若开启
validate_password插件，导入前需临时禁用：SET GLOBAL validate_password.policy = LOW; - MySQL 8.0+ 用户创建必须显式指定插件：
CREATE USER 'app_user'@'10.20.30.%' IDENTIFIED WITH caching_sha2_password BY 'StrongPass!2026'; - 生产环境建议统一用
caching_sha2_password，但需确保客户端驱动支持（如 Python 的 PyMySQL ≥ 0.9.3）
真正难的不是导出权限，而是识别哪些权限在开发环境“看起来合理”，但在生产中属于过度授权——比如 DROP、FILE、PROCESS 这类权限，往往只在调试时临时需要，绝不能保留在生产账号里。
