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