MySQL 8.0角色功能需四步：创建、授权、分配、激活，缺一不可；否则SHOW GRANTS可见角色而CURRENT_ROLE()返回NULL，权限不生效。
MySQL 8.0 的角色功能不是“开了就能用”，而是必须显式创建、授权、分配、再激活，四步缺一不可；否则 SHOW GRANTS 看得见角色，CURRENT_ROLE() 返回 NULL，权限实际不生效。
CREATE ROLE 和 DROP ROLE 必须带引号，且主机名不能省略随意匹配
角色名语法和用户账户一致，是 'role_name'@'host' 形式。省略 @'host' 默认为 @'%'，但后续分配给用户时若主机不匹配会失败。
-
CREATE ROLE 'app_ro'@'localhost';和CREATE ROLE 'app_ro';创建的是两个不同角色（后者等价于'app_ro'@'%'） - 删除前必须确保无用户持有该角色，否则
DROP ROLE 'app_ro';会报错ERROR 3530 (HY000): Cannot drop role 'app_ro'@'%' because it is granted to one or more users - 批量创建支持逗号分隔：
CREATE ROLE 'dev_role', 'qa_role', 'ops_role';，但所有角色都默认落在@'%'
GRANT 权限给角色 ≠ GRANT 角色给用户，两步不能合并
常见错误是以为 GRANT SELECT ON db.* TO 'alice'@'localhost'; 后再 GRANT 'app_ro' TO 'alice'@'localhost'; 就完事了——其实前者授的是直接权限，后者才是角色绑定，二者独立存在。
- 给角色授予权限：例如
GRANT SELECT, SHOW DATABASES ON *.* TO 'app_ro'; - 把角色赋予用户：例如
GRANT 'app_ro' TO 'alice'@'localhost'; - 用户被授予角色后，
SHOW GRANTS FOR 'alice'@'localhost';只显示GRANT USAGE ON *.* TO 'alice'@'localhost'和GRANT 'app_ro' TO 'alice'@'localhost';，**不会展开角色内含的权限** - 要查角色本身有哪些权限，必须执行
SHOW GRANTS FOR 'app_ro';
SET DEFAULT ROLE 是权限生效的关键开关，不设就等于没给
用户登录后，即使被授予了角色，CURRENT_ROLE() 仍返回 NULL，所有角色权限不可用。必须通过 SET DEFAULT ROLE 显式指定哪些角色在登录时自动激活。
- 激活单个角色：
SET DEFAULT ROLE 'app_ro' TO 'alice'@'localhost'; - 激活所有已授予角色：
SET DEFAULT ROLE ALL TO 'alice'@'localhost'; - 若用
SET PERSIST activate_all_roles_on_login = ON;全局开启自动激活，所有新连接都会默认激活全部显式授予的角色（但强制性角色仍需单独配置mandatory_roles） - 注意：
SET DEFAULT ROLE必须由有APPLICATION_PASSWORD_ADMIN或SYSTEM_VARIABLES_ADMIN权限的管理员执行，普通用户无法自行设置
REVOKE 角色后权限立即失效，但 CURRENT_ROLE() 不自动清空
撤销角色后，用户当前会话中 CURRENT_ROLE() 仍可能返回旧值，但这只是缓存状态；后续语句会因权限缺失报错，比如 SELECT 报 ERROR 1142 (42000): SELECT command denied to user。
- 撤销角色：
REVOKE 'app_ro' FROM 'alice'@'localhost'; - 撤销角色内的某项权限：
REVOKE INSERT ON app_db.* FROM 'app_ro';—— 这会影响所有持有该角色的用户 - 若想验证是否真失效，不要只看
CURRENT_ROLE()，而要实际执行一条受控语句，如SELECT DATABASE();或SHOW TABLES; - 已激活的角色被
REVOKE后，无需手动SET ROLE NONE，下次登录或新建会话即自然失效
最容易被忽略的是：角色权限变更（比如 GRANT/REVOKE 某个表权限）会实时影响所有持有该角色的用户，没有缓存、不依赖重连——这点和直接授给用户的权限行为一致，但正因为太“即时”，反而容易在灰度调整时误伤其他服务账号。
