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，不改变这个核心机制。
