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