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 —— 后者返回登录身份，前者才是权限判定依据。
