mysql 8.0角色本身不提升安全性，而是使最小权限原则可落地：直接grant用户需重复操作且难回收，而role通过create role→grant权限→grant角色→set default role四步实现集中管控、自动继承与审计可溯。
MySQL 8.0 的角色（ROLE）本身不提升安全性，它只是让“最小权限原则”真正可落地的工具；滥用或跳过关键步骤反而会放大风险。
为什么直接 GRANT 用户不如用 ROLE？
传统方式下，给 20 个开发人员都授 SELECT 权限，就得执行 20 次 GRANT SELECT ON app_db.* TO 'userX'@'10.20.%'。一旦某天要回收某类权限（比如禁用对日志表的访问），必须逐个 REVOKE，极易遗漏。
用 ROLE 后，只需两步：
- 建角色：
CREATE ROLE 'dev_readonly'; - 统一赋权：
GRANT SELECT ON app_db.users TO 'dev_readonly'; GRANT SELECT ON app_db.orders TO 'dev_readonly';
后续权限调整只改角色定义，所有绑定该角色的用户自动继承——不是“更安全”，而是“更可控、更可审计”。
SET DEFAULT ROLE 不执行，新权限就无效
这是最常被忽略的致命环节：即使你已执行 GRANT 'dev_readonly' TO 'alice'@'%'，alice 下次登录时也不会自动拥有该角色权限，除非显式激活。
必须补上这句才能立即生效：
-
SET DEFAULT ROLE 'dev_readonly' TO 'alice'@'%';（设为默认，以后每次登录都带） - 或临时切换：
SET ROLE 'dev_readonly';（仅当前会话）
否则你会看到现象：权限明明 GRANT 了，但用户一连库就报 ERROR 1044 (42000): Access denied，排查时容易误判为授权失败。
角色不能跨环境混用，哪怕权限内容一样
生产账号 'prod_app'@'172.16.31.%' 和测试账号 'test_app'@'10.0.2.%' 绝不能共用同一个角色名（如 'app_rw'）。原因有二：
- 权限变更时无法做环境灰度：你改了
'app_rw'，测试和生产同时受影响 - 审计日志里查不到来源：
GRANT 'app_rw' TO 'prod_app'@'172.16.31.%'看不出这个角色是否还绑定了开发机上的临时账号
正确做法是严格命名隔离：'prod_app_rw'、'staging_app_rw'、'dev_local_rw'，哪怕它们当前权限完全一致。
角色不是用户，别把它当登录凭证用
CREATE ROLE 创建的是纯权限容器，它没有密码、不能连接数据库、也不在 mysql.user 表中存记录。常见错误包括：
- 试图用角色名连库：
mysql -u dev_readonly -p→ 报错Access denied for user 'dev_readonly'@'localhost' - 给角色设密码：
ALTER USER 'dev_readonly'@'%' IDENTIFIED BY 'xxx';→ 报错ERROR 3925 (HY000): Role 'dev_readonly'@'%' does not exist
角色只服务于授权逻辑，所有连接行为仍由真实用户完成。它的存在意义，是把“谁有什么权限”从“谁是谁”里解耦出来——这点没理清，就容易在脚本里写错主体、在监控里漏掉权限链路。
