MySQL 8.0角色机制必须严格按创建→授权→分配→激活四步执行，缺一不可；否则CURRENT_ROLE()返回NULL，DML操作报ERROR 1045。需确认版本≥8.0.1、activate_all_roles_on_login=ON且mysql.role_edges表存在，角色名须带单引号并显式指定主机，权限须精确到库表，批量GRANT后必须SET DEFAULT ROLE激活。
MySQL 8.0 的角色机制不是“建完就能用”，多人开发权限管理必须走通创建→授权→分配→激活四步，缺一不可；否则 CURRENT_ROLE() 返回 NULL，所有 DML 操作都会报 ERROR 1045 (28000): Access denied。
确认 MySQL 版本和角色系统是否真正可用
执行 SELECT VERSION(); 是第一步，不能跳过。返回值必须是 8.0.1 或更高——8.0.0、5.7.42 等都不可用，CREATE ROLE 会直接触发 ERROR 1064 (42000)，这不是语法错，是功能根本不存在。
版本达标后，还需验证角色系统是否启用：
-
SHOW VARIABLES LIKE 'activate_all_roles_on_login';必须返回ON，否则新连接不会自动激活角色 -
SELECT * FROM mysql.role_edges LIMIT 1;必须能查出记录，否则说明实例未启用角色（常见于精简版或旧配置） - 若需持久化，必须在
my.cnf中添加：[mysqld] activate_all_roles_on_login=ON
创建角色并授予最小必要 DML 权限
开发角色名必须带单引号且显式指定主机，例如 'dev_role'@'%'。省略 @'host' 虽默认为 @'%'，但后续绑定用户时若主机不一致（如用户是 'alice'@'localhost'），可能因匹配逻辑失败导致权限静默不生效。
权限粒度要收严，避免越权：
- 只授业务库，禁用系统库：
GRANT SELECT, INSERT, UPDATE, DELETE ON dev_db.* TO 'dev_role'@'%'; - 视图操作需额外
GRANT SHOW VIEW，INSERT不隐含SELECT，哪怕只是INSERT ... SELECT也得单独给SELECT - 禁止
WITH GRANT OPTION，防止开发人员把权限再授给他人 -
REVOKE ALL PRIVILEGES ON mysql.* FROM 'dev_role'@'%';显式拒绝系统库访问
批量分配角色并确保默认激活
仅执行 GRANT 'dev_role' TO 'u1'@'%', 'u2'@'%'; 是无效的——权限不会落地，用户登录后 CURRENT_ROLE() 仍是 NULL。必须额外执行 SET DEFAULT ROLE 激活。
关键约束：
- 目标用户必须已存在，否则
GRANT静默跳过（无报错但不生效） - 所有用户的
host部分必须完全一致，例如'dev1'@'192.168.50.%'和'dev2'@'192.168.50.%'可批量处理；'dev1'@'%'和'dev2'@'localhost'就不行 - 激活方式选其一：
SET DEFAULT ROLE 'dev_role'@'%' TO 'u1'@'%';（单角色）SET DEFAULT ROLE ALL TO 'u1'@'%';（全部已授角色） - 若想全局生效，需管理员执行：
SET PERSIST activate_all_roles_on_login = ON;（需SYSTEM_VARIABLES_ADMIN权限）
验证权限是否真正生效
别只看 SHOW GRANTS FOR 'u1'@'%'; ——它只显示 GRANT 'dev_role' TO ...，不会展开角色内含权限。真正验证要分两步：
- 用目标用户登录后执行：
SELECT CURRENT_ROLE();，返回非NULL值才算激活成功 - 立刻执行实际操作，例如：
SELECT COUNT(*) FROM dev_db.users;或INSERT INTO dev_db.logs VALUES (...); - 查角色本身权限用：
SHOW GRANTS FOR 'dev_role'@'%'; - 注意：角色不能嵌套，
GRANT r2 TO r1再GRANT r1 TO u在 MySQL 8.0 中非法
最容易被忽略的是：即使 activate_all_roles_on_login = ON，如果用户从未被显式执行过 SET DEFAULT ROLE，首次连接时仍不会激活任何角色——这个“默认激活”只对已设默认角色的用户生效，不是全局兜底行为。
