MySQL迁移后GRANT语句失效主因有三：目标库缺失数据库/用户/主机匹配、8.0+严格模式拒绝废弃语法、权限导出未处理CREATE USER与GRANT依赖顺序；需先查版本与用户状态，再用CREATE USER重建基础账号，手动编写最小化GRANT语句并验证。
MySQL迁移后GRANT语句失效的常见原因
直接导出SHOW GRANTS FOR 'user'@'host'再在新实例执行，大概率失败——新库没有对应数据库、用户甚至主机名不匹配都会让GRANT报错。更隐蔽的是：MySQL 8.0+默认启用sql_mode=STRICT_TRANS_TABLES，旧库导出的权限语句若含已废弃语法（比如USAGE后面跟了不存在的权限），会直接拒绝执行。
- 先确认目标实例版本：
SELECT VERSION();，8.0+需检查mysql.user表结构是否含authentication_string字段（取代password） - 导出权限前，用
SELECT user,host,account_locked FROM mysql.user;核对源库用户状态，锁定用户不能简单复用GRANT - 避免直接
mysqldump --no-data --routines --triggers导出权限，它不处理CREATE USER与GRANT的依赖顺序
如何安全重建用户并映射最小权限
迁移不是“复制权限”，而是重新评估每个用户在新环境的实际需要。比如应用账号通常只需SELECT,INSERT,UPDATE特定库表，而非ALL PRIVILEGES；监控账号可能只要PROCESS,REPLICATION CLIENT等全局权限。
- 用
SELECT CONCAT('CREATE USER ''',user,'''@''',host,''' IDENTIFIED WITH mysql_native_password AS ''',authentication_string,''';') FROM mysql.user WHERE user != 'root';生成基础用户创建语句（注意8.0+密码字段名） - 逐个查用户实际权限：
SELECT table_schema,table_name,privilege_type FROM role_table_grants WHERE grantee = "'user'@'host'"（角色授权）或SELECT * FROM information_schema.role_routine_grants - 对每个用户，手动写
GRANT语句，显式指定ON db.table，禁用WITH GRANT OPTION——除非真有分级授权需求
FLUSH PRIVILEGES什么时候必须执行
只有通过直接修改mysql.user等系统表方式变更权限时，才需要FLUSH PRIVILEGES。所有正规CREATE USER/GRANT操作都自动生效，执行FLUSH反而暴露操作不规范。
- 如果迁移脚本里混用了
INSERT INTO mysql.user和GRANT，务必把FLUSH PRIVILEGES放在所有INSERT之后、GRANT之前 - MySQL 8.0+中，
FLUSH PRIVILEGES不会刷新角色权限缓存，需用SET ROLE DEFAULT或重新连接 - 执行后验证：
SHOW GRANTS FOR 'user'@'host';，确认输出与预期一致，且不含USAGE以外的隐式权限
权限同步后最易忽略的三个点
权限映射完成不等于安全落地。很多团队卡在最后一步：应用连不上、备份任务失败、监控指标缺失，问题往往不在权限本身，而在上下文细节。
-
host值必须精确匹配：源库用'app'@'10.20.%'，新库不能简写成'app'@'%'，否则可能被'app'@'localhost'规则覆盖 - 存储过程/函数调用依赖
DEFINER，迁移后若DEFINER='admin'@'192.168.1.%'用户不存在，调用会报Access denied，需用ALTER DEFINER重置 - Percona Toolkit或pt-online-schema-change等工具依赖
SUPER或REPLICATION SLAVE权限，这些常被漏掉，但又不能随便给——建议单独建pt_user账号专用于运维操作
