MySQL 8.0 默认禁用角色功能，创建角色失败主因是当前用户缺乏CREATE ROLE权限；需root授权后方可创建，且角色需显式绑定并激活才生效。
MySQL 8.0 中角色创建失败：ERROR 3716 (HY000)
这是最常卡住的第一步——你执行了 CREATE ROLE 'analyst' 却报错，核心原因是 MySQL 8.0 默认关闭了角色功能，必须显式启用。
-
sql_mode不影响角色，但activate_all_roles_on_login=OFF是默认值，不影响创建，只影响登录后自动激活 - 真正要检查的是全局变量
check_proxy_users和role_support？不，MySQL 8.0+ 没有role_support变量，角色支持是编译时内置的，无需开关 - 实际原因通常是用户没有
CREATE ROLE权限，且当前登录用户不是root或未被显式授权 - 解决方法：用 root 登录后先执行
GRANT CREATE ROLE ON *.* TO 'admin'@'%'; FLUSH PRIVILEGES;，再切换到admin创建角色
给角色授予权限后，用户仍无法访问表
角色本身不自动生效，它只是权限容器；用户必须显式 SET ROLE 或登录时激活，否则权限处于“挂起”状态。
- 创建角色并授权后，必须再执行
GRANT 'analyst' TO 'alice'@'localhost';，否则用户和角色之间没绑定 - 绑定后，用户登录时默认不会激活该角色，需额外执行
SET ROLE 'analyst';，或在创建用户时指定默认角色：ALTER USER 'alice'@'localhost' DEFAULT ROLE 'analyst'; - 如果用客户端工具（如 DBeaver、MySQL Workbench）连接，有些会复用连接池，
SET ROLE只对当前会话有效，断开重连就失效 - 验证是否生效：执行
SELECT CURRENT_ROLE();，返回'analyst'才算激活成功
撤销角色权限却不小心删掉了用户权限
MySQL 的权限模型里，角色权限和用户直授权限是叠加的，但 DROP ROLE 或 REVOKE 操作容易误伤。
-
REVOKE SELECT ON sales.* FROM 'analyst';是安全的，只动角色权限 - 但
REVOKE SELECT ON sales.* FROM 'alice'@'localhost';会直接删掉用户 alice 的该权限，哪怕她只是通过角色继承来的——MySQL 不区分来源，一律清除 - 更危险的是
DROP ROLE 'analyst';：它会立刻移除所有已授予该角色的用户与角色的绑定关系，但不会回收用户已有的直授权限；不过如果用户只靠这个角色访问，那她将瞬间失去全部相关权限 - 建议操作前先查清依赖：
SELECT * FROM mysql.role_edges WHERE TO_HOST = 'analyst';（注意：系统表名大小写敏感，MySQL 8.0 中是role_edges，不是role_edge）
角色嵌套（角色包含角色）在生产环境慎用
MySQL 8.0 支持角色嵌套，比如 GRANT 'developer' TO 'senior_dev';，但层级一深就难排查权限来源。
- 嵌套深度无硬性限制，但
SHOW GRANTS FOR 'alice'@'localhost';只显示直接授予的权限和角色，不展开嵌套角色里的内容 - 想看完整权限图谱，得手动递归查
mysql.role_edges表，脚本易出错，DBA 排查故障时基本靠猜 - 复制环境或主从部署中，角色定义同步正常，但
role_edges表变更可能因 GTID 或 binlog 格式问题延迟，导致从库角色绑定滞后 - 简单场景够用，但一旦涉及多团队共用角色（如 shared_readonly、hr_analytics），优先拆成扁平角色 + 显式授权，别图省事嵌套
角色管理真正的复杂点不在语法，而在权限生命周期——谁创建、谁维护、谁审计、过期怎么清理。一个没被 REVOKE 的角色绑定，可能让离职员工的账号依然保有访问权限，而日志里只记了 SET ROLE，不记原始授权路径。
