mysql 8.0.1+才支持角色功能，必须按四步闭环操作：确认版本≥8.0.1、启用activate_all_roles_on_login、创建并授权角色、grant角色给用户且set default role激活；任一缺失均导致权限不生效。
MySQL 8.0.1+ 才真正支持角色功能，低于这个版本（比如 8.0.0 或 5.7）执行 CREATE ROLE 会直接报 ERROR 1064 (42000)——不是你写错了，是功能根本不存在。
确认 MySQL 版本和角色系统是否就绪
跳过这步，后面所有操作都白忙。必须按顺序验证三项：
- 执行
SELECT VERSION();，确保返回值 ≥8.0.1 - 执行
SHOW VARIABLES LIKE 'activate_all_roles_on_login';，值必须为ON；若为OFF，用户登录后角色不会自动激活 - 执行
SELECT 1 FROM mysql.role_edges LIMIT 1;，不报错才说明角色元数据表已启用（极少数精简版 MySQL 缺失该表）
任一条件不满足，CREATE ROLE 可能静默失败或报 ERROR 3719、ERROR 3530，别猜原因，先查这三项。
创建角色并授予具体库表权限
角色本身是空壳，CREATE ROLE 只建了个名字，不赋权等于没配。权限必须显式授予角色，且语法有硬限制：
- 角色名必须带单引号，推荐写全主机段，如
'dev_role'@'%'，避免后续GRANT时因 host 不匹配失败 -
GRANT目标必须是库级或表级，不能写GRANT SELECT ON *.table_name（语法错误），正确写法是GRANT SELECT ON dev_db.*或GRANT SELECT ON dev_db.users - 别加
WITH GRANT OPTION到角色上——开发人员拿到后可能把权限再授给他人，安全风险高 - 系统库默认禁止访问，但显式拒绝更稳妥：
REVOKE ALL PRIVILEGES ON mysql.* FROM 'dev_role'@'%';
示例：
CREATE ROLE 'dev_role'@'%'; GRANT SELECT, INSERT, UPDATE, DELETE ON dev_db.* TO 'dev_role'@'%'; GRANT CREATE, DROP, ALTER, INDEX, CREATE VIEW, SHOW VIEW, EXECUTE ON dev_db.* TO 'dev_role'@'%';
批量绑定角色并激活，默认不生效
只执行 GRANT 'dev_role' TO 'u1'@'%', 'u2'@'%' 是无效的——用户登录后 CURRENT_ROLE() 仍返回 NULL，权限不可用。必须显式激活：
- 用户必须已存在，否则
GRANT会静默跳过（无报错但不生效） - 所有用户的 host 部分必须完全一致，比如
'u1'@'192.168.50.%'和'u2'@'192.168.50.%'可批量处理；混用'%'和'localhost'会导致SET DEFAULT ROLE失败 - 激活命令需高权限：执行者要有
APPLICATION_PASSWORD_ADMIN或SYSTEM_VARIABLES_ADMIN权限 - 激活语句：
SET DEFAULT ROLE ALL TO 'u1'@'192.168.50.%', 'u2'@'192.168.50.%'
如果用户还没设默认角色，也可以用 ALTER USER 'u1'@'%' DEFAULT ROLE 'dev_role'@'%';，但前提是该角色已被 GRANT 过权限，否则激活后仍是空权限。
权限变更后如何立即生效
给角色新增权限或回收权限后，已登录用户不会自动继承——他们的会话权限缓存不变。必须做两件事：
- 执行
FLUSH PRIVILEGES;刷新全局权限缓存 - 让目标用户断开重连，或在其会话内手动执行
SET ROLE 'dev_role'@'%';
最容易被忽略的是：FLUSH PRIVILEGES 不是可选步骤，它是角色权限对新连接生效的必要条件。生产环境改完权限不刷，就会出现“明明授了权，用户还是没权限”的现象。
