mysql中权限表的存储与管理机制

MySQL权限信息全部存放在mysql系统数据库中，含user、db等8张核心权限表，均为InnoDB引擎；直接UPDATE权限表不生效，因权限校验依赖内存缓存，须用GRANT语句并执行FLUSH PRIVILEGES刷新。

MySQL权限表存在哪些系统库中

MySQL的权限信息全部存放在 mysql 系统数据库里，不是独立文件也不是内存常驻结构。5.7 及以后版本中，mysql 库下共 31 张表（含视图），其中核心权限表有 8 张，最常用的是：user、db、tables_priv、columns_priv、procs_priv、proxies_priv、default_roles、role_edges。

这些表是 InnoDB 引擎，支持事务和崩溃恢复，但 MySQL 启动时会将部分权限缓存到内存（如 user 表中的全局权限），所以直接改表不生效，必须执行 FLUSH PRIVILEGES 或重启服务才能刷新内存缓存。

为什么不能直接用 UPDATE 修改权限表

直接 UPDATE mysql.user SET authentication_string = PASSWORD('xxx') WHERE User = 'test' 这类操作在 5.7+ 版本会失败或被忽略，原因有三：

• MySQL 服务端在

  

  启动时读取 mysql.user 并构建内存权限树，后续所有权限校验都走内存副本，不实时查表
• 部分字段（如 authentication_string）受插件逻辑控制，比如 caching_sha2_password 插件要求哈希格式严格匹配，手动拼接易出错
• 权限表之间有强依赖（例如 role_edges 和 default_roles 联动角色继承），单表更新极易破坏一致性

正确做法永远是用授权语句：GRANT SELECT ON mydb.* TO 'u1'@'localhost';，它会自动同步写入对应表并刷新内存缓存。

GRANT 和 INSERT 权限表的区别在哪

GRANT 是 MySQL 提供的权限管理接口，它不只是写表，还承担校验、归一化、缓存刷新、事件触发等职责；而直接 INSERT INTO mysql.db 属于绕过校验的底层操作，风险极高：

• GRANT 会自动补全缺失字段（如 ssl_type、max_questions 默认为 0），手写 INSERT 忘记设值会导致权限行为异常
• GRANT 对 host 字段做模糊匹配处理（如 '%' 和 '' 的语义差异），手动插入可能误用空字符串导致权限失效
• 某些权限（如 SYSTEM_VARIABLES_ADMIN）只在 8.0+ 支持，且需配合 SET PERSIST 才能持久化，INSERT 写表完全无效

GRANT INSERT, UPDATE ON sales.* TO 'app'@'10.20.%';
-- 等价于安全地更新 mysql.db 表 + 刷新权限缓存
-- 不等价于：
INSERT INTO mysql.db (Host, Db, User, Select_priv, Insert_priv, Update_priv) 
VALUES ('10.20.%', 'sales', 'app', 'N', 'Y', 'Y');

权限表修改后不生效的常见排查点

即使用了 GRANT，权限仍不生效，大概率卡在这几个环节：

• 客户端连接时使用的 User@Host 和权限表中记录不完全匹配（注意：host 匹配是精确的，'%' ≠ 'localhost'，Unix socket 登录默认走 localhost，不是 127.0.0.1）
• 执行 GRANT 的用户本身没有 GRANT OPTION 权限，语句看似成功但实际没写入
• MySQL 配置了 skip-grant-tables，此时所有权限检查被跳过，表内容完全无效
• 使用了角色（CREATE ROLE r1; SET DEFAULT ROLE r1 TO 'u1'@'%';），但忘了给角色赋权，或没激活角色（SET ROLE r1;）

查当前会话有效权限用：SHOW GRANTS FOR CURRENT_USER();，不是 CURRENT_USER —— 后者返回登录身份，前者才是权限判定依据。