权限存在哪几张系统表里？
MySQL 的所有权限信息都存放在
mysql这个系统数据库的多张表中，不是配置文件，也不是内存变量——改完必须刷缓存或重启才生效（但推荐刷缓存）。关键表有五张，按权限粒度从大到小排列：
mysql.user：全局权限，决定用户能否连上、能否关服务、能否建库等。只要这里某字段是
Y，就跳过后续检查（比如
Delete_priv = 'Y'，该用户就能删任意库的任意行）
mysql.db：库级权限，控制对某个库的
SELECT/
CREATE等操作。注意：只对显式指定库名的语句生效（如
SELECT * FROM sales.orders），不带库名的
USE sales; SELECT *也受它管
mysql.tables_priv：表级权限，精确到某张表。字段
Table_name和
Db联合定位对象，
Table_priv存权限字符串（如
'Select,Insert'）
mysql.columns_priv：列级权限，细到某一列，比如只允许更新
users.phone，但不能碰
users.id_card
mysql.procs_priv：存储过程/函数执行权限，和
EXECUTE权限直接对应
这些表在 MySQL 8.0+ 全部用
InnoDB引擎（事务安全），不再是 MyISAM；但服务器启动时仍会把它们加载进内存缓存，所以你直接
INSERT INTO mysql.user不会立刻生效——必须
FLUSH PRIVILEGES或重启。
为什么 GRANT 后有时不生效？常见刷新陷阱
很多人执行了
GRANT SELECT ON app.* TO 'dev'@'%'，但应用还是报
Access denied。根本原因不是语法错，而是权限没“活”过来。MySQL 不是实时监听权限表变更，它靠内存快照做鉴权。 正确做法永远用
GRANT/
REVOKE语句，而不是手改
mysql.*表（MySQL 8.0+ 甚至禁止直接写
user表）
GRANT语句内部会自动触发权限重载，**但仅限当前连接会话**；其他已连接的客户端仍用旧快照 新连接一定生效；老连接要重连，或你手动执行
FLUSH PRIVILEGES（这个命令强制全量重载所有权限表到内存） 如果用了代理（如 ProxySQL）、连接池（如 HikariCP），更要小心——连接可能复用很久，权限变更后实际生效时间远滞后
mysql> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.01 sec)
权限匹配顺序：为什么同一个用户名从不同 IP 登录权限不同？
MySQL 认证不是只看用户名，而是严格匹配
user@host二元组。更关键的是权限检查走的是「自顶向下短路匹配」：先查
user表，命中就停，不再往下查
db表。 例如：用户
'api'@'10.0.2.%'在
user表里
Select_priv = 'N'，但在
db表里对
finance库有
Select_priv = 'Y'→ 他能查
finance库 但如果
'api'@'10.0.2.%'在
user表里
Super_priv = 'Y'，那他就拥有全部权限，
db表的设置完全被忽略 反过来，
'api'@'localhost'是另一个完全独立的账号，哪怕密码一样，权限也得单独配
这种设计让 DBA 可以实现「同一人，本地全权、远程受限」，但也是权限混乱的源头——别漏掉
@'%'和
@'localhost'的重复创建。
MySQL 8.0+ 的权限表结构变化要点
MySQL 8.0 彻底重构了权限系统，新增表、拆分字段、强化安全，默认行为也变了：
废弃password字段，改用
authentication_string存哈希值（SHA256-based） 新增
global_grants表管理动态全局权限（如
BACKUP_ADMIN），和传统
user表里的静态权限分离 新增
role_edges和
default_roles支持角色（Role）机制，可批量授权、解耦用户与权限 创建用户必须显式
CREATE USER，不能再用
GRANT ... IDENTIFIED BY一步到位（该语法已弃用） 密码策略默认启用：
validate_password插件强制长度、复杂度，
PASSWORD EXPIRE可设周期
如果你从 5.7 升级上来，用
mysqldump --all-databases备份再恢复，权限表结构会自动适配；但直接拷贝
mysql库文件会失败——InnoDB 表空间不兼容。
