mysql无权限继承机制，角色授权实为权限副本复制，需显式赋权与刷新缓存；全局授权on .不覆盖新建库表，权限静态绑定系统表；唯一可靠复用方式是角色+显式授权+默认角色。
MySQL 不存在传统意义上的“权限继承”
MySQL 没有像 PostgreSQL 的 INHERIT 或 Windows ACL 那样的层级式权限继承机制。所谓“角色继承权限”，本质是角色被显式授予（GRANT）了某些权限，再把角色赋给用户——用户获得的是角色所拥有的**已授予权限的副本**，而非动态继承。一旦角色权限变更，必须手动执行 FLUSH PRIVILEGES（仅旧版本需）或确保元数据缓存刷新（8.0+ 通常自动），否则新权限不会立即生效。
如何用角色模拟“权限继承”效果
MySQL 8.0+ 支持角色（Role），这是最接近“继承”的实践方式：
CREATE ROLE 'dev_role';- 给角色授予权限：
GRANT SELECT, INSERT ON mydb.* TO 'dev_role'; - 把角色赋予用户：
GRANT 'dev_role' TO 'alice'@'%'; - 激活角色（会话级）：
SET ROLE 'dev_role';，或设为默认：SET DEFAULT ROLE 'dev_role' TO 'alice'@'%';
注意：用户必须先有 USAGE 权限才能被授角色；角色本身不自动激活，需显式 SET ROLE 或配置默认角色。
为什么直接 GRANT ON *.* 不等于“继承”
执行 GRANT SELECT ON *.* TO 'user'@'%'; 看似“全局授权”，但实际含义是：对当前已存在且用户有访问权限的数据库中的所有表授予 SELECT。它不会自动覆盖后续新建的数据库，也不会向下传递到新创建的表或列——MySQL 权限是静态绑定在 mysql.db、mysql.tables_priv 等系统表中的记录，没有运行时查找父级策略的逻辑。
常见误解场景：
- 新建库
newdb后，原GRANT ... ON *.*用户无法访问——因为该授权未写入mysql.db对应新库的行 - 对库授了
SELECT，但没对具体表或列授权，而表里有敏感字段，权限粒度仍由最细一级（如mysql.columns_priv）最终决定 -
GRANT ALL PRIVILEGES ON *.*在严格模式下可能因缺少GRANT OPTION而失败，且不包含PROXY或CREATE USER等管理权限
容易踩坑的权限“伪继承”操作
以下操作看似能复用权限，实则隐含风险或失效条件：
- 复制用户（
CREATE USER 'newuser'@'%' IDENTIFIED BY 'pwd' LIKE 'olduser'@'%';）：仅复制认证信息，不复制权限——必须额外GRANT或从mysql.user手动导出权限语句 - 用
mysqldump mysql.user mysql.db mysql.tables_priv迁移权限：表结构和数据需严格匹配目标版本，8.0+ 的authentication_string和密码历史字段易出错 - 依赖
root用户权限“自动覆盖子账户”：完全不存在；root的高权限只作用于自身会话，不影响其他用户权限判定 - 误以为
GRANT ... WITH GRANT OPTION是继承开关：它只允许该用户继续向他人授出**自己已被授予的同级权限**，不能越权，也不能跨层级“生成”新权限
真正可控的复用路径只有角色 + 显式授权 + 默认角色设置。任何绕过 GRANT 语句的“自动同步”都不可靠。
