MySQL权限数据存储在mysql系统库的user、db、tables_priv、columns_priv、procs_priv和proxies_priv六张表中，均使用MyISAM引擎。
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() 和登录凭据不一致时，几乎必踩坑。
