MySQL权限信息全部存放在mysql系统数据库中，含user、db等8张核心权限表，均为InnoDB引擎；直接UPDATE权限表不生效，因权限校验依赖内存缓存，须用GRANT语句并执行FLUSH PRIVILEGES刷新。
MySQL权限表存在哪些系统库中
MySQL的权限信息全部存放在
系统数据库里，不是独立文件也不是内存常驻结构。5.7 及以后版本中，
库下共 31 张表（含视图），其中核心权限表有 8 张，最常用的是：
、
、
、
、
、
、
、
。
这些表是 InnoDB 引擎，支持事务和崩溃恢复，但 MySQL 启动时会将部分权限缓存到内存（如
表中的全局权限），所以直接改表不生效，必须执行
或重启服务才能刷新内存缓存。
为什么不能直接用 UPDATE 修改权限表
直接
这类操作在 5.7+ 版本会失败或被忽略，原因有三：
MySQL 服务端在启动时读取
并构建内存权限树，后续所有权限校验都走内存副本，不实时查表
部分字段（如
）受插件逻辑控制，比如
插件要求哈希格式严格匹配，手动拼接易出错
权限表之间有强依赖（例如
和
联动角色继承），单表更新极易破坏一致性
正确做法永远是用授权语句：
，它会自动同步写入对应表并刷新内存缓存。
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
GRANT 和 INSERT 权限表的区别在哪
是 MySQL 提供的权限管理接口，它不只是写表，还承担校验、归一化、缓存刷新、事件触发等职责；而直接
属于绕过校验的底层操作，风险极高：
会自动补全缺失字段（如
、
默认为 0），手写
忘记设值会导致权限行为异常
对 host 字段做模糊匹配处理（如
和
的语义差异），手动插入可能误用空字符串导致权限失效
某些权限（如
）只在 8.0+ 支持，且需配合
才能持久化，
写表完全无效
权限表修改后不生效的常见排查点
即使用了
，权限仍不生效，大概率卡在这几个环节：
客户端连接时使用的
和权限表中记录不完全匹配（注意：host 匹配是精确的，
，Unix socket 登录默认走
，不是
）
执行
的用户本身没有
权限，语句看似成功但实际没写入
MySQL 配置了
，此时所有权限检查被跳过，表内容完全无效
使用了角色（
），但忘了给角色赋权，或没激活角色（
）
查当前会话有效权限用：
，不是
—— 后者返回登录身份，前者才是权限判定依据。
mysqlmysqluserdbtables_privcolumns_privprocs_privproxies_privdefault_rolesrole_edgesuserFLUSH PRIVILEGESUPDATE mysql.user SET authentication_string = PASSWORD('xxx') WHERE User = 'test'mysql.userauthentication_stringcaching_sha2_passwordrole_edgesdefault_rolesGRANT SELECT ON mydb.* TO 'u1'@'localhost';GRANTINSERT INTO mysql.dbGRANTssl_typemax_questionsINSERTGRANT'%'''SYSTEM_VARIABLES_ADMINSET PERSISTINSERTGRANT 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');GRANTUser@Host'%' ≠ 'localhost'localhost127.0.0.1GRANTGRANT OPTIONskip-grant-tablesCREATE ROLE r1; SET DEFAULT ROLE r1 TO 'u1'@'%';SET ROLE r1;SHOW GRANTS FOR CURRENT_USER();CURRENT_USER