MySQL权限表存在哪些，各自控制什么范围
MySQL的权限控制完全依赖系统库
mysql下的几张核心表，不是靠配置文件或外部服务。最关键的五张表是：
user、
db、
tables_priv、
columns_priv和
procs_priv（MySQL 8.0+ 还增加了
role_edges和
default_roles支持角色）。
它们按优先级从高到低生效：连接级（
user）→ 数据库级（
db）→ 表级（
tables_priv）→ 字段级（
columns_priv）→ 存储过程/函数级（
procs_priv）。只要某一级显式拒绝（
Deny），就不会继续向下检查。
user表决定「能否连上服务器」以及全局操作权限（如
CREATE USER、
SHUTDOWN），字段如
host、
user、
authentication_string、
ssl_type、各类
_priv布尔字段
db表绑定
host+
user+
db三元组，控制对某个数据库的
SELECT/
INSERT等权限，但不包含对象创建类权限（如
CREATE ROUTINE）
tables_priv和
columns_priv使用
Table_name和
Column_name字段做细粒度限制，注意它们的
Timestamp和
Grantor字段是只读的，由 MySQL 自动维护
GRANT / REVOKE 语句和直接改权限表的区别
必须用
GRANT或
REVOKE操作权限，不能直接
UPDATE或
INSERT权限表 —— 否则权限不会实时生效，且可能破坏表结构一致性（比如
user表的
plugin和
account_locked字段在不同版本中含义不同）。
执行
GRANT后，MySQL 会自动刷新内存中的权限缓存（
mysqld内部的
acl_cache），但某些极端情况（如复制延迟、并发修改）可能导致短暂不一致。此时可手动执行
FLUSH PRIVILEGES强制重载，不过这仅在绕过
GRANT直接改表后才需要，正常流程下不需要。 用
GRANT SELECT ON mydb.* TO 'u1'@'192.168.1.%'会同时写入
db表和更新
user表的
max_questions等资源限制字段（如果指定了）
REVOKE ALL PRIVILEGES ON *.* FROM 'u1'@'%'不会删除该用户记录，只是清空其所有权限字段；要删用户得用
DROP USERMySQL 8.0+ 默认启用
sql_mode = 'STRICT_TRANS_TABLES'，对权限字段赋值非法值（如给
Select_priv设为
'xyz'）会报错，而旧版本可能静默转成
'N'
常见权限错误现象与排查路径
用户报 “Access denied” 却确认账号密码正确，大概率是权限匹配失败，而非认证问题。重点查三件事：
host是否精确匹配、权限是否已生效、是否有显式拒绝规则。
执行
SELECT user(), current_user();可区分「你声称是谁」和「MySQL认定你是谁」——后者由
user表中
host字段的最长匹配规则决定（比如
'u1'@'192.168.%'优先于
'u1'@'%'）。再用
SHOW GRANTS FOR 'u1'@'192.168.1.100';查当前生效权限，它会合并所有层级的授权结果。 错误信息
ERROR 1045 (28000): Access denied for user 'u1'@'localhost' (using password: YES)：说明连接时
host解析为
localhost，但
user表里只有
'u1'@'127.0.0.1'记录（二者不等价） 执行
SELECT报
ERROR 1142 (42000): SELECT command denied to user ...：检查
db表是否存在对应
host+
user+
db记录，且
Select_priv='Y'使用通配符库名（如
myapp_%）需确保 SQL 模式未开启
ANSI_QUOTES，否则反引号包裹的库名会被当字面量处理
MySQL 8.0 权限模型的关键变化
MySQL 8.0 彻底重构了权限系统，最明显的是将原来分散在
user表里的几十个布尔权限字段（如
File_priv、
Process_priv）统一归入
role概念，并通过
role_edges表管理角色继承关系。这意味着：老版本靠
UPDATE mysql.user SET File_priv='Y' WHERE user='u1';开启文件权限的方式，在 8.0+ 已失效。
现在必须用
CREATE ROLE 'backup_admin'; GRANT FILE ON *.* TO 'backup_admin'; GRANT 'backup_admin' TO 'u1'@'%';，再执行
SET DEFAULT ROLE 'backup_admin' TO 'u1'@'%';才能让权限生效。角色权限默认不自动激活，需显式
SET ROLE或设为默认角色。
password_expired字段被移除，改由
password_history和
password_reuse_interval系统变量控制
mysql.session和
mysql.sys这两个内置账户不再出现在
user表查询结果中（即使加
SQL_NO_CACHE），它们受独立内核机制保护 权限检查路径变长：用户 → 角色 → 权限 → 对象匹配，任意一环失败即拒绝，调试时
SHOW GRANTS输出也更复杂
权限表本身不加密，敏感字段如
authentication_string是哈希值，但整个
mysql库若被导出，仍可能被离线爆破。生产环境务必限制对
mysql库的
SELECT权限，尤其禁止普通用户查
user表。
