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 表 + 自定义脚本，既不标准也不推荐用于生产。
