MySQL 8.0 的角色功能需显式启用：必须设置 activate_all_roles_on_login = ON，CREATE ROLE 后需 GRANT 权限，角色名区分大小写，不支持嵌套，SET ROLE 切换即时生效且互斥，权限变更实时同步。
MySQL 8.0 的 CREATE ROLE 和 DROP ROLE 必须显式启用角色功能
MySQL 8.0 默认不激活角色（Role）功能，即使你执行了 CREATE ROLE 'analyst'，后续 GRANT 也不生效——因为系统变量 activate_all_roles_on_login 默认为 OFF，且新创建的角色不会自动被用户识别。
必须先运行：
SET GLOBAL activate_all_roles_on_login = ON;
并确保 mysql 系统库中存在角色定义（CREATE ROLE 会写入 mysql.role_edges 表），否则 SHOW ROLES 查不到、SET ROLE 报错 ERROR 3530 (HY000): Cannot grant role 'analyst' to 'user1'@'%': role does not exist。
-
CREATE ROLE后需立即用GRANT绑定权限，否则角色是空壳 - 角色名区分大小写，
'Analyst'和'analyst'是两个不同角色 - 若用 MySQL Shell（mysqlsh）连接，默认使用 SQL 模式，但
SET ROLE在某些客户端（如旧版 Workbench）可能不触发上下文切换，建议用命令行验证
用 GRANT ... TO role_name 分配 DML 权限比逐个用户授权更可控
传统方式给 20 个开发人员每人 SELECT, INSERT, UPDATE 权限到 sales.*，要执行 20 次 GRANT；改用角色后，只需两步：
CREATE ROLE 'dml_sales';<br>GRANT SELECT, INSERT, UPDATE ON sales.* TO 'dml_sales';
再批量绑定用户：
GRANT 'dml_sales' TO 'dev1'@'%', 'dev2'@'%', 'dev3'@'%';
注意：GRANT role_name TO user 不会自动激活该角色，用户登录后仍需显式执行 SET ROLE 'dml_sales' 才能获得对应权限（除非已设 activate_all_roles_on_login = ON）。
- 角色不能嵌套递归：MySQL 8.0 不支持
GRANT r2 TO r1再GRANT r1 TO u这种链式继承 -
INSERT权限不隐含SELECT，哪怕只是想用INSERT ... SELECT，也得额外GRANT SELECT - 对视图（View）授 DML 权限时，目标列必须有底层表对应列的权限，否则报
ERROR 1142 (42000): INSERT command denied to user
SET ROLE 切换角色时权限即时生效，但会覆盖当前会话所有其他角色
一个用户被授予多个角色（如 'dml_sales' 和 'readonly_hr'），默认登录后只激活默认角色（由 SET DEFAULT ROLE 指定）。执行 SET ROLE 'dml_sales' 后，'readonly_hr' 的权限立刻失效——这不是 bug，而是 MySQL 的会话级角色模型设计。
若需同时启用多个角色，必须用：
SET ROLE 'dml_sales', 'readonly_hr';
或一次性激活全部已授权角色：
SET ROLE ALL;
-
SET ROLE NONE会清空当前会话所有角色权限，回到仅剩账户自身直授权限的状态 - 角色权限变更（如管理员 revoke 了某个角色的
UPDATE）会实时反映在已激活该角色的会话中，无需重连 - 存储过程内无法执行
SET ROLE，报错ERROR 1370 (42000): execute command denied to user，因角色切换属于会话控制操作
回收权限别只 REVOKE 角色，记得检查用户直授权限是否残留
当你要把某人从销售组调去财务组，执行 REVOKE 'dml_sales' FROM 'user1'@'%' 很自然，但容易忽略：如果之前曾直接给 'user1'@'%' 授过 UPDATE sales.orders，这个权限不会随角色撤销而消失。
查用户实际拥有的全部权限（含直授 + 角色继承）用：
SHOW GRANTS FOR 'user1'@'%';
它返回的是“合并后”的结果，但不区分来源。要定位直授权限，得查：
SELECT * FROM mysql.tables_priv WHERE User='user1' AND Host='%';
- 角色本身可被
DROP ROLE，但若仍有用户持有该角色，会报ERROR 3526 (HY000): Cannot drop role 'dml_sales' because it is granted to one or more users -
FLUSH PRIVILEGES对角色无效，角色元数据缓存在内存中，变更立即可见 - 备份恢复时，
mysql.role_edges和mysql.default_roles表必须一并导出，否则角色关系丢失
角色管理真正省力的地方不在创建，而在权限调整窗口期——比如临时禁用某组用户的 DELETE 权限，只需 REVOKE DELETE ON sales.* FROM 'dml_sales'，所有绑定该角色的用户立刻同步受限。这点很容易被当成“理所当然”，但恰恰是手动维护用户粒度权限时最难收敛的点。
