mysql用户和权限有什么关系_mysql账号模型解析

mysql用户与权限分离存储于多张系统表，按层级匹配；GRANT/REVOKE安全操作多表权限，DROP USER自动清理关联记录，角色是8.0+权限复用机制。

MySQL 用户和权限是绑定在同一套账号模型里的：没有用户，权限无处依附；没有权限，用户只能连上却干不了任何事。用户身份由 'user'@'host' 唯一确定，而权限则按层级（全局、库、表、列）分散存储在多个系统表中，不是“一个用户一条权限记录”那么简单。

用户本质就是 mysql.user 表里的一行记录

创建用户，本质上是在 mysql.user 表中插入一条包含 host、user 和 authentication_string 的记录。这三个字段构成联合主键，意味着：

• 'admin'@'localhost' 和 'admin'@'%' 是两个完全独立的用户，权限互不影响
• 修改密码、禁用账户、限制连接数（如 max_connections），都是直接更新这行里的对应字段
• 千万别用 UPDATE mysql.user SET ... 手动改权限字段（比如把 select_priv 改成 'Y'），因为 MySQL 5.7+ 不会自动刷新内存权限缓存，必须跟 FLUSH PRIVILEGES; 配合，否则行为不可预测

权限不是存在用户身上，而是分层查表匹配出来的

当你执行 SELECT * FROM orders;，MySQL 不是看“这个用户有没有 SELECT 权”，而是按固定顺序查 6 张授权表：

• 先查 mysql.user：有全局 Select_priv='Y'？有就放行，结束
• 没命中，再查 mysql.db：当前库 orders 是否允许该用户从当前 host 访问？且 Select_priv='Y'？
• 还没命中，继续查 mysql.tables_priv（表级）、mysql.columns_priv（列级）……直到找到第一条匹配项
• 全部不匹配 → 报错 Error 1142 (42000): SELECT command denied to user...

这意味着：即使你在 user 表里把所有权限都设为 'N'，只要 db 表里有一条匹配的 SELECT 记录，查询照样能过。

GRANT 并不“修改用户”，而是在多张表里写入权限记录

运行 GRANT SELECT ON mydb.* TO 'u1'@'192.168.%';，MySQL 实际做了两件事：

• 如果 'u1'@'192.168.%' 还不存在，先在 mysql.user 插入一行（仅含基础字段，权限全为 'N'）
• 在 mysql.db 表中插入或更新一条记录，其中 Db='mydb'、User='u1'、Host='192.168.%'、Select_priv='Y'

所以：

• GRANT 和 REVOKE 是安全的操作方式，它们会自动处理多表一致性
• 用 DROP USER 'u1'@'192.168.%' 删除用户时，MySQL 会同时清理 user、db、tables_priv 等所有关联权限记录
• 但如果你只删了 user 表某行（比如用 delete FROM mysql.user WHERE ...），那些残留在 db 表里的“孤儿权限”不会自动清除，可能造成权限残留或误判

角色（Role）是 MySQL 8.0+ 的权限复用机制，不是用户组别名

MySQL 的 ROLE 不是 linux 那种“组账号”，它本身不能登录，只是一个权限容器。使用流程是：

• CREATE ROLE 'analyst';
• GRANT SELECT, SHOW VIEW ON sales.* TO 'analyst';
• GRANT 'analyst' TO 'alice'@'%', 'bob'@'%';

关键点：

• 用户被授予角色后，需执行 SET ROLE 'analyst'; 才能激活该角色权限（除非设为默认角色）
• 角色权限可动态增减，所有持有该角色的用户权限实时同步（无需逐个 GRANT）
• 但角色不能嵌套（GRANT r1 TO r2 不合法），也不能跨实例迁移——导出权限时，角色定义和授权语句必须一起导出，否则目标库会报 Unknown role

最常被忽略的是：MySQL 5.7 及更早版本根本没有 ROLE，所谓“模拟角色”靠的是 proxies_priv 表 + 自定义脚本，既不标准也不推荐用于生产。