MySQL 的权限数据存在哪几张系统表里
MySQL 的 ACL（Access Control List）权限信息全部存储在
mysql系统数据库的几张核心表中，不是内存结构或配置文件。主要涉及：
user、
db、
tables_priv、
columns_priv、
procs_priv和
proxies_priv。其中：
user表控制全局权限（如
SELECT、
RELOAD），也决定用户能否连接服务器；
db表控制某用户对特定数据库的权限，粒度比
user细，但不包含表级操作；
tables_priv和
columns_priv分别支持表级和列级权限，启用时需注意性能开销（每次查询都需额外校验）； 所有这些表都使用 MyISAM 引擎（即使你用的是 InnoDB 默认引擎），因为需要表锁+快速读，且不支持事务。
GRANT 语句到底做了什么
GRANT不是直接改内存，而是写入上述系统表，并触发权限缓存刷新。执行后 MySQL 会自动调用
FLUSH PRIVILEGES的等效逻辑（5.7+ 版本），但仅限于由
GRANT/
REVOKE发起的操作；手动修改
mysql.user表后仍必须显式执行
FLUSH PRIVILEGES。 权限是“累加”的：同一个用户对同一资源的多条
GRANT会合并权限位，不会覆盖；
GRANT OPTION权限本身不赋予实际操作能力，只允许该用户再把已有权限授予他人； 如果用
GRANT ... WITH GRANT OPTION授予了某权限，之后用
REVOKE撤销该权限时，所有由该用户转授的下游权限也会被级联清除（5.7.4+ 默认行为）； 注意
USAGE权限：它表示“无任何特权”，仅用于创建用户但不赋权，
GRANT USAGE ON *.* TO 'u'@'%'是合法的。
权限匹配顺序为什么总是报 “Access denied”
MySQL 权限检查按固定顺序逐层匹配：先查
user表（host + user），若匹配成功但权限字段全为
N，则拒绝连接；否则继续向下查
db、
tables_priv等。关键点在于： 匹配是“最长 host 前缀优先”，比如
'user'@'192.168.1.%'和
'user'@'192.168.1.100'同时存在，后者更精确，会被优先选中； 空字符串
''在
host字段中代表“任意主机”，但优先级最低； 用户名区分大小写（取决于
lower_case_table_names设置），而 host 部分始终不区分大小写； 常见误判：执行
SELECT USER(), CURRENT_USER();，前者返回客户端声明的用户/主机，后者返回实际匹配到的
user@host条目——二者不一致就说明有多个匹配项，MySQL 选了你没预期到的那个。
动态权限（MySQL 8.0+）和传统 ACL 的关键区别
MySQL 8.0 引入了角色（
ROLE）和动态权限（如
BACKUP_ADMIN、
CONNECTION_ADMIN），它们不存于旧的
mysql.user表中，而是在
mysql.role_edges和
mysql.global_grants中管理。 动态权限不能用
GRANT ... ON *.*语法，必须用
GRANT role_name TO user或
GRANT dynamic_priv ON *.* TO user； 传统权限（如
SELECT）仍走老 ACL 流程；动态权限只影响管理类操作，不影响 DML；
SHOW GRANTS FOR 'u'@'h'会同时列出传统权限和动态权限，但
mysql.user表里看不到动态权限字段； 升级到 8.0 后，旧用户不会自动获得新动态权限，也不受影响；但如果你用
CREATE USER创建新用户，默认会附带
APPLICATION_PASSWORD_ADMIN等隐式权限，容易引发意外交互。
SELECT * FROM mysql.global_grants WHERE user = 'admin' AND host = '%';
ACL 的真实复杂性不在语法，而在权限叠加、host 匹配歧义、以及 8.0 后双模型并存带来的调试盲区——尤其当
CURRENT_USER()和登录凭据不一致时，几乎必踩坑。
