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() 和登录凭据不一致时，几乎必踩坑。