云数据库权限丢失主因是模型差异：禁用直接操作mysql系统库、不支持WITH GRANT OPTION、强制host限制及DEFINER失效；须通过控制台创建用户、显式ALTER USER指定插件、逐对象GRANT并验证全链路访问。
迁移后权限丢失不是“没给够”，而是云数据库的权限模型、用户认证方式和访问控制逻辑与自建库存在结构性差异。直接复用旧库的 mysqldump --all-databases 或 INSERT INTO mysql.user 语句，大概率导致用户无法登录、USE 报错、事件静默失效或应用连得上但查不了表。
为什么云数据库里 SHOW GRANTS 看着对，实际却没权限？
云数据库（如阿里云 RDS、腾讯云 CDB）通常禁用直接写 mysql 系统库，也不允许 GRANT OPTION 下放给普通账号。这意味着：
- 你导出的旧权限 SQL 中含
GRANT ... WITH GRANT OPTION，在云库执行会报错或被忽略 -
SHOW GRANTS FOR 'user'@'%'显示结果可能来自云平台内部权限映射层，而非真实mysql.db表，不能作为生效依据 - 云环境默认关闭
event_scheduler，且不支持自定义DEFINER用户——即使你导了mysql.event，事件也不会触发 - 部分云厂商强制要求用户 host 必须为
%或指定 IP 段，'user'@'localhost'在云库中根本不可用
迁移前必须导出的权限信息，不止是 GRANT 语句
只导 SHOW GRANTS 输出远远不够。云数据库重建权限时，需人工补全三类关键元数据：
-
CREATE USER语句本身：重点看IDENTIFIED WITH插件类型（mysql_native_password还是caching_sha2_password），云厂商控制台创建用户时默认插件可能与旧库不一致 - 用户连接限制：如
MAX_CONNECTIONS_PER_HOUR、MAX_QUERIES_PER_HOUR，这些在自建库里常被忽略，但在云库中会被严格 enforce，超限即断连 - 数据库级对象依赖：比如视图、存储过程里的
DEFINER、函数里的SQL SECURITY DEFINER，这些不会随业务库导入自动生效，必须单独处理
推荐导出命令：mysqldump --no-create-info --skip-extended-insert -u root -p mysql user db procs_priv > pre_migrate_grants.sql，再用 grep -E "(User|Host|plugin|authentication_string)" pre_migrate_grants.sql 提取认证关键字段。
云数据库上重建权限的实操要点
不要在云库上执行任何 INSERT INTO mysql.*；所有操作必须通过控制台或标准 SQL 接口完成：
- 先用云平台控制台创建用户，确保
host填写为%或精确 IP 段（不能留空或填localhost） - 创建后立即执行：
ALTER USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd';（除非确认客户端支持caching_sha2_password） - 授予权限时，显式指定库名+表名：
GRANT SELECT, INSERT ON \`myapp\`.\`orders\` TO 'u'@'%';，避免用ON *.*（云库通常禁止） - 涉及视图/函数/事件的，必须用目标用户重新
CREATE OR REPLACE，否则DEFINER仍指向旧用户，运行时报ERROR 1449
最容易被跳过的验证环节：应用层连接池与缓存
权限配置完，mysql -u u -p -h rds.xxx.com 能连、能 USE、能 SELECT，不代表应用就正常。常见断点：
- Java 应用连接池（如 HikariCP）缓存了旧用户的认证上下文，重启服务前需清空连接池或设置
clearPool参数 - PHP 的
mysqlnd扩展在长连接中可能复用旧 handshake 结果，需重启 PHP-FPM - 应用自身权限缓存（如 Spring Security 的
FilterSecurityInterceptor或自研 RBAC 缓存）未刷新，导致接口返回 403 而非数据库报错
真正可靠的验证，是让应用以目标用户身份完整走一遍核心链路：建连接 → 开事务 → 查配置表 → 写日志表 → 提交 —— 中间任一环节卡住，都要回溯对应层级的权限配置，而不是只盯 SHOW GRANTS 输出。
