权限是操作能力，角色是权限的打包容器
权限（Privilege）是数据库里最细粒度的控制单元，比如
SELECT、
INSERT、
DROP，它直接决定“能不能执行某条 SQL”。角色（Role）本身不干活，只是把一堆权限捆在一起，像一个可复用的权限模板。用户不能直接“拥有角色”，而是通过
GRANT role_name TO user@host获得角色所含的所有权限——本质是权限继承，不是逻辑分组。
MySQL 角色管理依赖显式激活，不自动生效
这是最容易踩坑的地方：创建角色并授权后，用户登录并不会自动获得该角色权限。必须手动激活，否则
SELECT都会报
Access denied： 会话级激活：
SET ROLE role_dev;（仅当前连接有效） 默认激活（推荐）：
SET DEFAULT ROLE role_dev TO 'dev01'@'localhost';全局默认（8.0.16+）：
SET PERSIST default_role = 'role_dev';，影响新连接
没执行
SET DEFAULT ROLE就以为权限已生效，是线上权限故障的高频原因。
角色权限检查仍走传统授权表，但叠加逻辑更复杂
MySQL 权限校验顺序仍是先查
mysql.user（全局）、再
mysql.db（库级）等系统表，但角色引入了“间接路径”：用户 → 角色 → 角色的权限记录（存于
mysql.role_edges和
mysql.role_routine_grants等新表）。这意味着： 撤销角色权限时，要同时考虑直接授给用户的权限和角色带来的权限，避免残留
SHOW GRANTS FOR 'u'@'h'默认只显示直接授予的权限，加
FOR u@h WITH ADMIN OPTION才能看到角色链 角色嵌套（A→B→C）在 8.0.20+ 才完全支持，低版本嵌套会静默失败
用户和角色在语法上几乎对称，但语义不可互换
你可以用
CREATE ROLE r1;和
CREATE USER u1@'%' IDENTIFIED BY 'pwd';，也能对两者都执行
GRANT SELECT ON db.* TO r1;，看起来一样——但关键区别在于： 角色不能登录，没有密码字段，不能出现在
mysql.user表中 角色不能被
REVOKE ... FROM直接删掉，必须先
DROP ROLE r1;用户可拥有多个角色，角色也可被多个用户持有，但角色之间不能循环授权（如 r1 → r2 → r1）
混淆用户与角色的生命周期管理，比如误删一个被广泛授予的角色，会导致一批用户瞬间失权，且无日志提示具体影响范围。
