SHOW GRANTS FOR 'alice'@'%' USING 'app_writer' 仅显示该角色直接授予的权限，不递归展开其依赖角色（如 app_reader、base_role）的权限；需结合 mysql.role_edges 和 INFORMATION_SCHEMA.APPLICABLE_ROLES 分步验证完整权限链。
SHOW GRANTS FOR user USING role 不展开嵌套权限
执行 SHOW GRANTS FOR 'alice'@'%' USING 'app_writer' 只会显示 app_writer 这个角色**自身被直接授予的权限语句**，不会递归列出它所依赖的 app_reader 或 base_role 的权限。这是最常被误解的一点：语句里写了 USING，但 MySQL 并不自动“展开继承链”。
常见错误是看到输出里没有 SELECT 就以为用户没这权限，其实 app_writer 可能只是个中转角色，真正给 SELECT 的是它上游的另一个角色。
- 必须对每个上游角色单独再跑一次
SHOW GRANTS FOR ... USING ... -
USING不校验该角色是否已被激活——即使语句能执行，权限也不一定当前生效 - 若角色链为 A→B→C→用户，
SHOW GRANTS USING 'A'和USING 'B'是两件事，得分别查
查 mysql.role_edges 表获取父子关系
mysql.role_edges 是唯一记录角色授予关系的系统表，字段含义固定：FROM_USER 是被授出的角色（父），TO_USER 是接收者（子）。它不表示权限自动传递，只表示“谁把谁加进了自己的角色列表”。
例如查 app_writer 直接依赖哪些角色：
SELECT FROM_USER, FROM_HOST FROM mysql.role_edges WHERE TO_USER = 'app_writer' AND TO_HOST = '%';
查 base_role 被哪些角色引用（即它的下游）：
SELECT TO_USER, TO_HOST FROM mysql.role_edges WHERE FROM_USER = 'base_role' AND FROM_HOST = '%';
- 该表不保证无环，MySQL 8.0.14+ 才支持 CTE 递归查询，但需手动写多层 JOIN 或脚本拼接完整链
-
FROM_HOST和TO_HOST必须匹配，不能忽略（比如'%'≠'localhost'） - 删掉一个角色（
DROP ROLE）不会自动清理role_edges中残留的边，得人工核对
权限是否实际生效，得看 INFORMATION_SCHEMA.APPLICABLE_ROLES
角色链存在 ≠ 权限可用。用户登录后，必须通过 SET ROLE 或默认角色机制激活，权限才进入会话上下文。未激活的角色，哪怕在 role_edges 里层层嵌套，也等于不存在。
查当前会话已激活的角色：
SELECT * FROM INFORMATION_SCHEMA.APPLICABLE_ROLES WHERE IS_ASSIGNED = 'YES';
查某用户（如 'dev'@'10.%'）被授予的所有角色（含未激活）：
SELECT ROLE_NAME FROM INFORMATION_SCHEMA.ADMINISTRABLE_ROLE_AUTHORIZATIONS WHERE GRANTEE = '''dev''@''10.%''';
-
CURRENT_ROLE()只返回当前生效的那个角色，不是全部 -
IS_ASSIGNED = 'YES'是硬性开关，没这个就别指望SELECT能过 - 角色激活状态和
role_edges数据是两个独立维度，必须同时验证
最终权限 = 直接授权 + 激活角色的权限语句拼合
没有单条 SQL 能输出“用户通过哪条路径获得了什么权限”。真实权限是三者叠加的结果：用户行里的全局权限（mysql.user）、显式授予的库/表级权限（mysql.db 等）、以及所有已激活角色的权限语句。
所以自动化巡检时必须分步处理：
- 先用
SHOW GRANTS FOR 'u'@'h'拿直接权限 - 再查
INFORMATION_SCHEMA.APPLICABLE_ROLES拿当前激活的角色列表 - 对每个激活角色，递归查
role_edges得到完整路径，再对路径上每个角色执行SHOW GRANTS FOR ... USING ... - 最后合并所有权限语句，去重、比对冲突（比如某表上一个角色给
SELECT，另一个给ALL）
最容易被忽略的是：角色链里任意一环没激活，整条链就断了；而 SHOW GRANTS 默认不显示角色权限，容易误判为“零权限”。
