mysql中权限继承与权限优先级的管理

MySQL 权限无真正继承，仅按匹配优先级生效：列级>表级>库级>全局，且 Host 越具体优先级越高；GRANT 累加不覆盖，角色仅为语法糖，底层仍依赖系统表匹配。

MySQL 权限继承只发生在用户账户层级，不跨数据库或表自动传递

MySQL 没有传统意义上的“角色继承”或“组权限继承”机制（直到 8.0 才引入 ROLE，但默认不启用且行为受限）。所谓“继承”，实际是指：当给用户授予 USAGE 或更细粒度权限时，MySQL 会把权限记录在 mysql.user、mysql.db、mysql.tables_priv 等系统表中，而这些表的匹配顺序决定了“谁的权限生效”。没有父级账号向子账号授予权限的语法，也没有 INHERIT FROM 这类语句。

常见误解是以为对 'user'@'%' 授予了 SELECT 就自动覆盖 'user'@'localhost' —— 实际上两者是完全独立的账号，权限互不影响。真正起作用的是「主机名匹配优先级」：MySQL 总是选择最具体的 Host 值匹配，比如 'user'@'192.168.1.100' 优先于 'user'@'192.168.%'，后者又优先于 'user'@'%'。

权限优先级由匹配粒度决定，不是“后授权者胜”

MySQL 不按授权时间先后判断优先级，而是严格按「权限 作用域 从细到粗」逐层匹配：

• mysql.columns_priv（列级）> mysql.tables_priv（表级）> mysql.db（库级）> mysql.user（全局）
• 同级别下，Host 字段越具体，匹配优先级越高（例如 'host-a' > '%.example.com' > '%'）
• user 表中的权限是兜底项：只有当更细粒度的权限表中没匹配到时，才用 user 表里的全局权限

这意味着：即使你先给 'app'@'%' 在 user 表里授了 ALL PRIVILEGES，再给 'app'@'10.0.1.5' 在 db 表里只授 SELECT，该用户从 10.0.1.5 连入时，只会拿到 SELECT，不会叠加或覆盖成 ALL —— 因为 db 表匹配成功，user 表就不再参与决策。

GRANT 语句不会自动撤销已有权限，需显式 REVOKE

执行 GRANT SELECT ON db1.* TO 'u'@'%'; 不会影响该用户在其他库上的已有权限，也不会清除它之前被授予的 INSERT 或 UPDATE。权限是“累加”的，除非你主动 REVOKE。

容易踩的坑：

• 误以为 GRANT SELECT ON *.* 会覆盖掉之前某个库的 DENY（MySQL 本身不支持 DENY 语法，所谓“拒绝”只能靠不授予权限或删掉对应记录）
• 用 FLUSH PRIVILEGES 强制重载权限表——其实 GRANT/REVOKE 会自动刷新，手动执行反而可能因缓存不一致引发问题
• 忘记权限作用域：对 'u'@'%' 执行 GRANT SELECT ON db1.*，不代表 'u'@'localhost' 也能访问 db1

检查当前用户实际生效权限，用：

SHOW GRANTS FOR 'u'@'%';

注意：该命令只显示 GRANT 语句记录，不反映最终运行时权限（比如未在 db 表中显式授权，但 user 表中有全局 SELECT，SHOW GRANTS 就不会体现）。

MySQL 8.0+ 的 ROLE 机制仍需手动激活，且不改变底层匹配逻辑

虽然 MySQL 8.0 引入了 CREATE ROLE 和 SET DEFAULT ROLE，但它只是语法糖，底层仍依赖原有权限表。角色本身没有“继承链”，也不能嵌套赋权（GRANT r1 TO r2 非法）。

关键限制：

• 角色必须被显式赋予用户：GRANT r1 TO 'u'@'%';
• 用户登录后默认不激活角色，需执行 SET ROLE r1; 或配置 SET DEFAULT ROLE r1 TO 'u'@'%';
• 角色权限仍受前述匹配规则约束：如果用户自身在 user 表中有 DROP，但角色只给了 SELECT，那用户依然能 DROP —— 角色不是沙箱，只是权限集合的快捷方式

真正影响权限生效的，永远是 mysql.*_priv 表中那几行记录的 Host/User/Db/Table/Column 字段组合是否匹配当前连接上下文。任何“继承”或“角色”都只是帮你少写几条 GRANT，不改变这个核心机制。