CREATE ROLE报错ERROR 1064说明MySQL版本低于8.0.1，角色功能不支持；需先执行SELECT VERSION()确认版本，5.7仅能手动维护用户级权限，8.0.1+才支持角色创建、授权、分配及SET DEFAULT ROLE激活全流程。
CREATE ROLE 报错 ERROR 1064 是版本问题，不是语法写错了
执行 CREATE ROLE 'app_reader' 直接报错 ERROR 1064 (42000)，基本可以断定 MySQL 版本低于 8.0.1。角色是原生功能，5.7 及更早版本根本不识别该语句，硬套只会失败。
- 先确认版本：
SELECT VERSION();，输出如5.7.42或8.0.0就得停手 - 5.7 只能靠人工维护用户级权限，比如反复执行
GRANT SELECT ON mydb.* TO 'u1'@'%'，没有角色抽象层 - MySQL 8.0.1+ 才真正支持角色；升级前别在测试环境用 8.0.0，它不带角色功能
GRANT TO 角色和 GRANT TO 用户，两步缺一不可
建好角色、赋完权限，用户还是查不了表？大概率漏了“把角色分给人”这步。角色只是空容器，不绑定到用户就等于没装进去。
- 给角色授权：
GRANT SELECT, INSERT ON app_db.* TO 'app_writer' - 再把角色分配给用户：
GRANT 'app_writer' TO 'dev_user'@'localhost' - 最后设为默认（否则登录后权限为空）：
SET DEFAULT ROLE 'app_writer' TO 'dev_user'@'localhost'
少任何一步，SHOW GRANTS FOR 'dev_user'@'localhost' 都只显示 USAGE，看起来像没权限。
SHOW GRANTS 看不到角色权限，容易误判实际能力
SHOW GRANTS FOR 'user'@'host' 只返回直接授予该用户的权限，完全不体现角色继承的权限。你看到的是“纸面权限”，不是“真实权限”。
- 想确认用户实际有哪些角色：
SELECT * FROM mysql.role_edges WHERE TO_HOST = 'localhost' AND TO_USER = 'dev_user'; - 查某个角色具体有哪些权限：
SHOW GRANTS FOR 'app_reader' - 看当前会话激活了什么角色：
SELECT CURRENT_ROLE();
DBA 审计时如果只扫 SHOW GRANTS 输出，很可能放行一个其实拥有 DBA 权限的账号。
REVOKE FROM 后面跟角色名 or 用户名，决定影响范围
回收权限时，FROM 后面的对象类型直接决定操作粒度——改的是角色定义本身，还是某个人的直授权限。
- 从角色撤权（批量生效）：
REVOKE INSERT ON app_db.* FROM 'app_writer'→ 所有被授此角色的用户立刻失去 INSERT - 从用户撤角色（单点回收）：
REVOKE 'app_writer' FROM 'dev_user'@'localhost'→ 只影响这个用户，不影响角色定义和其他人 - 误写成
REVOKE INSERT ON app_db.* FROM 'dev_user'@'localhost'→ 只影响该用户的直授权限，对角色无感
生产环境执行前务必核对 FROM 后是角色名还是用户名，输错一个字符，要么收不干净，要么收过头。
