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