MySQL 8.0查看角色成员关系：查询information_schema.role_column_grants详解

在MySQL 8.0的权限体系中，列级权限的管理算得上是一个精细活儿。尤其是当权限通过角色（Role）来授予时，排查问题往往会多绕一个弯。今天，我们就来彻底理清，如何精准地查询角色级别的列权限，以及如何找到这些权限的最终使用者。

查角色对某列的授权：直接读 ROLE_COLUMN_GRANTS

想搞清楚一个角色到底被授予了哪些列权限，最直接的入口就是 ROLE_COLUMN_GRANTS 这个视图。它是MySQL 8.0.19版本才引入的“专案组”，只负责记录角色这一层的列级授权关系，用户直接被授予的列权限不归它管。

这里有个常见的坑：你执行查询，结果却返回空。先别急着怀疑人生，大概率是这两个原因之一：要么你的MySQL版本低于8.0.19，要么你要查的权限根本不是列级的（比如是表级或库级授权）。

具体怎么操作？记住下面几步：

• 先验明正身：用 SELECT VERSION(); 确认版本号，必须≥8.0.19。
• 精准查询：比如，要查角色 'myrole'@'%' 对 mydb.t1 表某列的UPDATE权限，可以这样写：

  SELECT GRANTEE, TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, PRIVILEGE_TYPE
  FROM INFORMATION_SCHEMA.ROLE_COLUMN_GRANTS
  WHERE GRANTEE = 'myrole'@'%'
    AND TABLE_SCHEMA = 'mydb'
    AND TABLE_NAME = 't1'
    AND PRIVILEGE_TYPE = 'UPDATE';

• 注意字段含义：结果里的 GRANTEE 字段是角色名（格式如 'app_writer'@'%'），不是最终的用户账号。想知道“谁拥有这个角色”，还得结合其他视图来关联查询。

查谁持有某角色：关联 APPLICABLE_ROLES 与 ROLE_COLUMN_GRANTS

光知道角色有什么权限还不够，关键得找到权限的“活水源头”——也就是当前哪些用户激活并持有着这个角色。因为MySQL不会自动展开角色的权限链，ROLE_COLUMN_GRANTS 本身不包含用户信息，这就需要我们手动关联。

具体操作路径如下：

• 查看当前用户的活跃角色：直接运行 SELECT * FROM INFORMATION_SCHEMA.APPLICABLE_ROLES;，一目了然。
• 查看指定用户被授予的所有角色：比如查用户 'dev_user'@'localhost'，注意MySQL字符串的转义规则：

  SELECT ROLE_NAME, IS_GRANTABLE
  FROM INFORMATION_SCHEMA.ADMINISTRABLE_ROLE_AUTHORIZATIONS
  WHERE GRANTEE = '''dev_user''@''localhost''';

• 终极关联查询：将角色成员和列权限连起来。例如，找出所有能修改 mydb.t1.col_a 列的活跃用户：

  SELECT ar.ROLE_NAME, ar.GRANTEE
  FROM INFORMATION_SCHEMA.APPLICABLE_ROLES ar
  JOIN INFORMATION_SCHEMA.ROLE_COLUMN_GRANTS rcg
    ON ar.ROLE_NAME = SUBSTRING_INDEX(rcg.GRANTEE, '''', 1)
  WHERE rcg.TABLE_SCHEMA = 'mydb'
    AND rcg.TABLE_NAME = 't1'
    AND rcg.COLUMN_NAME = 'col_a'
    AND rcg.PRIVILEGE_TYPE = 'UPDATE';

为什么不能只靠 SHOW GRANTS FOR user？

很多朋友习惯用 SHOW GRANTS FOR 'u'@'h'，因为它看起来最直观。但这里有个关键局限：它只原样显示执行过的 GRANT 语句，既不会展开角色里具体包含什么权限，也不会合并列级权限的细节。

举个例子：角色 r_w 拥有 UPDATE(col_a) 权限，用户 u 被授予了角色 r_w。此时你用 SHOW GRANTS 查看用户 u 的权限，只会看到一句 GRANT r_w TO 'u'@'h'，至于角色里那个关键的列权限，只字不提。这在排查“为什么能更新其他列，唯独这一列报权限错误”时，简直就是走进了死胡同。

那么，正确的验证姿势是什么？

• 放弃幻想：首先得明确，MySQL没有像PostgreSQL那样的 has_column_privilege() 内置函数来直接校验。
• 可靠路径：最靠谱的方式，就是用目标用户账号实际连接数据库，然后查询 INFORMATION_SCHEMA.COLUMN_PRIVILEGES（查直接授权）或者在激活角色后查询 ROLE_COLUMN_GRANTS（查角色授权）。
• 故障定式：如果应用报错 ERROR 1142 (42000): UPDATE command denied，并且只针对某一列，那么十有八九是列级权限在作祟。这时应该直接跳转到上述两个视图去查，别在库级或表级权限视图里浪费时间。

容易被忽略的权限叠加逻辑

MySQL 8.0的权限生效机制，并不是简单的“取并集”。列级权限（COLUMN_PRIVILEGES）和角色列级权限（ROLE_COLUMN_GRANTS）是两条独立的授权路径，必须同时满足，权限才算真正到手。

举个例子：用户自己直接被授予了 UPDATE(col_a) 权限，同时又通过角色继承了 UPDATE(col_b) 权限，那么他对这两列都有操作权。但是，如果权限全部来自角色（比如角色只给了 UPDATE(col_a)），而用户自己没有获得任何直接的列权限，那么他就只能修改 col_a。这里有个关键点：即使该用户拥有整个表的 UPDATE 权限，列级限制的优先级更高，会覆盖掉更宽泛的表级授权。

最后几个实操要点，务必留心：

• 破除误解：千万别想当然地认为“有表级UPDATE权限就能改所有列”。列级权限是一个硬性的过滤器，优先级高于表级。
• 理解字段：ROLE_COLUMN_GRANTS 视图中的 IS_GRANTABLE 字段，只表示这个角色能否把权限再转授给别人，不影响当前角色持有者使用该权限。
• 关注开关：系统变量 activate_all_roles_on_login 至关重要。如果设置为 ON，用户登录时所有被授予的角色会自动激活，APPLICABLE_ROLES 里能看到全部。如果为 OFF，就必须显式执行 SET ROLE 来激活角色，否则，即便 ROLE_COLUMN_GRANTS 里有记录，对应的权限也不会生效。