MariaDB 10.4+需启用roled_support=ON才支持原生ROLE；CREATE ROLE后须用GRANT为角色赋权，再GRANT角色给用户；SET ROLE仅当前会话生效，需SET DEFAULT ROLE设默认角色；DROP ROLE前须先REVOKE依赖并检查role_edges。

创建角色前必须确认版本和权限模型

mariadb 10.4+ 才支持原生 role 语法，低于该版本用 create user 模拟角色会出问题。更重要的是，必须启用 roled_support=on（5.5.62+/10.0.38+ 默认开启，但某些旧部署可能被手动关掉）。检查方式：

select @@roled_support;

返回 off 就得改配置文件加 roled_support=on 并重启服务——不重启，create role 会直接报错 unknown command。

CREATE ROLE 后不能直接赋权？得用 GRANT 显式绑定

角色本身是空容器，创建完不赋权限等于没建。常见错误是以为 CREATE ROLE 'analyst' 就能用了，结果 SET ROLE 'analyst' 后查表还是 Access denied。正确流程是三步走：

• CREATE ROLE 'analyst';
• GRANT SELECT ON sales.* TO 'analyst';
• GRANT 'analyst' TO 'alice'@'localhost';

注意：第二步的 GRANT 是给角色授权，不是给用户；第三步才是把角色分配给用户。漏掉第二步，角色就是个摆设。

用户激活角色时容易忽略 SET ROLE 的作用域和持久性

SET ROLE 'analyst' 只在当前会话生效，断开重连就失效。想让新会话默认激活某个角色，得用：

SET DEFAULT ROLE 'analyst' TO 'alice'@'localhost';

否则每次连接都要手动 SET ROLE，脚本或应用里容易忘。另外，SET ROLE NONE 能临时退回到无角色状态，调试权限问题时比反复退出重连快得多。

删除角色前务必检查依赖，否则 DROP ROLE 会失败

如果已有用户被授予该角色，DROP ROLE 'analyst' 会报错 Cannot drop role; it is granted to one or more users。得先解绑：

REVOKE 'analyst' FROM 'alice'@'localhost';

再删。更隐蔽的问题是：角色可能被其他角色嵌套继承（MariaDB 支持角色嵌套），所以删之前最好查：

SELECT * FROM mysql.role_edges WHERE TO_HOST = 'analyst';

有记录就得先清理上游依赖。角色管理不像用户那么“孤立”，它本质是一张权限图谱里的节点。