SHOW GRANTS FOR ROLE 必须用单引号包裹角色名，如 'analyst_role'；仅显示该角色直授权限，不递归嵌套角色；列级权限需查 INFORMATION_SCHEMA.ROLE_COLUMN_GRANTS（8.0.19+）；权限需通过 SET ROLE 或默认角色激活才生效。
SHOW GRANTS FOR ROLE 语法必须带单引号
直接执行 SHOW GRANTS FOR ROLE analyst_role 会报错，因为 MySQL 要求角色名必须用单引号包裹。正确写法是：SHOW GRANTS FOR ROLE 'analyst_role'。漏掉引号或写成双引号都会触发 ERROR 1064 (42000)。这个限制和普通用户查权限（SHOW GRANTS FOR 'user'@'host'）一致，但容易被忽略——毕竟角色名看起来不像用户名那样天然带 host 部分。
角色权限不自动展开嵌套关系
SHOW GRANTS FOR ROLE 'app_writer' 只显示该角色自身被授予的权限，不会递归列出它所依赖的其他角色（比如 app_writer 被 GRANT 过 readonly_analyst）。如果你看到结果里只有 SELECT ON mydb.*，但实际使用时还能查 logdb，大概率是嵌套了别的角色。要验证这点，得查 mysql.role_edges：
- 查
app_writer是否被授给其他角色：SELECT TO_USER, TO_HOST FROM mysql.role_edges WHERE FROM_USER = 'app_writer' - 查谁把
app_writer当作子角色用了：SELECT FROM_USER, FROM_HOST FROM mysql.role_edges WHERE TO_USER = 'app_writer'
注意：字段方向靠值判断——FROM_USER 是“授予方”，TO_USER 是“接收方”；角色→角色、用户→角色都混在这张表里。
列级权限需额外查 INFORMATION_SCHEMA.ROLE_COLUMN_GRANTS
如果角色有列级权限（如只允许更新 users.email），SHOW GRANTS FOR ROLE 默认不显示。必须用 INFORMATION_SCHEMA.ROLE_COLUMN_GRANTS 查，且仅限 MySQL 8.0.19+：
- 确认版本：
SELECT VERSION()，低于8.0.19该视图不存在 - 查角色对某列的权限：
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, PRIVILEGE_TYPE FROM INFORMATION_SCHEMA.ROLE_COLUMN_GRANTS WHERE GRANTEE = '''app_writer'''@'''%'''（注意 MySQL 字符串转义：单引号要写两个） - 该视图不包含用户直授的列权限，只反映「角色」这一层的列授权
没查到结果？先排除两个常见原因：版本不够，或者权限其实是表级/库级的（那它根本不会进这张表）。
权限是否生效，还得看角色是否激活
SHOW GRANTS FOR ROLE 只告诉你“这个角色被给了哪些权限”，不保证当前会话能用。例如你用 root 执行该命令看到 INSERT ON orders.*，但普通用户连上去后执行 INSERT 报错，大概率是因为没执行 SET ROLE 'app_writer' 或没设默认角色。验证方式很简单：
- 登录目标用户后，运行
SELECT CURRENT_ROLE()，返回NULL表示没激活任何角色 - 执行
SET DEFAULT ROLE ALL TO 'dev_user'@'localhost'可让角色在下次登录时自动启用 - 临时启用：
SET ROLE 'app_writer'，之后再跑SHOW GRANTS FOR CURRENT_USER()就能看到合并后的权限
最易被忽略的一点：权限继承是静态映射，但生效是动态的——查到了，不等于能用；查不到，也不代表一定没权（可能走的是用户直授路径）。
