show grants for角色必须带主机名，如'app_reader'@'%'；返回仅直接授予的权限，不含间接继承权限；查角色持有者需反查用户或查询mysql.role_edges表。
SHOW GRANTS FOR role_name@'host' 语法必须带主机名
MySQL 8.0 的角色（role）是数据库级对象，但 SHOW GRANTS FOR 命令仍按「用户账户」语法解析——它不识别纯角色名。直接写 SHOW GRANTS FOR 'app_reader' 会报错 ERROR 1141 (42000): There is no such grant defined for user 'app_reader' on host '%'，因为 MySQL 默认补全为 'app_reader'@'%'，而角色没有 host 段。
正确做法是显式指定主机名为 '%'（角色创建时默认绑定该 host），即使你没在 CREATE ROLE 里写：
SHOW GRANTS FOR 'app_reader'@'%';
如果角色是用带 host 的方式创建的（比如 CREATE ROLE 'admin'@'localhost'），那这里也得严格匹配：SHOW GRANTS FOR 'admin'@'localhost'。
角色本身不存权限，只存「被授予的权限集合」
SHOW GRANTS FOR 返回的是该角色当前被显式授予的权限（即通过 GRANT ... TO role_name 添加的），不包括角色间接继承的权限（比如角色 A 被授给用户 B，B 再被授给角色 C —— 这种链式授权不会出现在 C 的 SHOW GRANTS 结果里）。
这意味着你看到的只是「角色直接拥有的权限」，不是它最终能行使的所有权限。要查角色实际生效权限，得结合 ROLE_TABLES 和 APPLICABLE_ROLES 视图，或模拟激活后查 INFORMATION_SCHEMA.ROLE_TABLE_GRANTS。
常见误判点：
- 看到
GRANT SELECT ON `sales`.* TO 'reporter'@'%'，就认为 reporter 能查所有 sales 库表 —— 实际上若该角色还被GRANT了其他角色（如WITH ADMIN OPTION授权链），这些不会列在这里 - 执行
SHOW GRANTS FOR 'reporter'@'%'返回空，不代表角色没权限 —— 可能只是它没被直接授过权限，而是通过其他角色间接获得
查看角色包含哪些用户/角色，要用 SHOW GRANTS FOR user_name
想确认某个角色被哪些用户或角色持有，不能对角色本身运行 SHOW GRANTS，而要反过来查用户：运行 SHOW GRANTS FOR 'alice'@'%' ，结果里会出现类似 GRANT 'app_reader'@'%' TO 'alice'@'%' 的行 —— 这表示 alice 持有 app_reader 角色。
MySQL 不提供「列出所有持有某角色的主体」的原生命令。替代方案是查系统表：
SELECT * FROM mysql.role_edges WHERE TO_HOST = '%' AND TO_USER = 'app_reader';
注意：该表字段名是 FROM_HOST/FROM_USER（被授权者）和 TO_HOST/TO_USER（角色名），顺序容易看反。
SHOW GRANTS 输出里的 WITH ADMIN OPTION 很关键
如果某行输出含 WITH ADMIN OPTION，说明该角色不仅能使用所授权限，还能把**相同角色**再授给其他用户或角色（注意：不是授出底层权限，而是授出这个角色本身）。
例如：
GRANT 'backup_admin'@'%' TO 'dbmgr'@'%' WITH ADMIN OPTION;
这时 dbmgr 就能执行 GRANT 'backup_admin'@'%' TO 'junior'@'%'。但若漏掉 WITH ADMIN OPTION，后续授权会报错 ERROR 3530 (HY000): Access denied; you need (at least one of) the SYSTEM_USER privilege(s) for this operation。
这个选项不会自动继承，每次 GRANT ... TO 都得显式加上，否则下游无法继续分发角色。
角色权限的「可见性」取决于你用什么账号执行 SHOW GRANTS：必须有 SELECT 权限访问 mysql.role_edges 和 mysql.proxies_priv 等系统表，否则连基本角色关系都查不到。普通账号默认看不到其他角色详情，这点比用户权限更严格。
