MySQL 8.0如何查看角色成员关系_查询information_schema.role_column

ROLE_COLUMN_GRANTS是MySQL 8.0.19+专用于查询角色列级权限的视图，仅反映角色层级授权，不包含用户直授权限；版本低于8.0.19或权限来自表/库级时查不到结果。

mysql 8.0如何查看角色成员关系_查询information_schema.role_column_grants

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

ROLE_COLUMN_GRANTS 是 MySQL 8.0.19+ 引入的专用视图，专用于查「角色」被授予了哪些「列级权限」。它不显示用户直授的列权限，只反映角色这一层的授权关系。

常见错误现象：执行 SELECT * FROM INFORMATION_SCHEMA.ROLE_COLUMN_GRANTS 返回空，但你知道某个角色确实有列权限——大概率是 MySQL 版本低于 8.0.19，或该角色权限来自表级/库级授权（不在这个表里）。

实操建议：

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

确认版本：SELECT VERSION()，必须 ≥ 8.0.19

查某角色对某库某表某列的 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 或 ADMINISTRABLE_ROLE_AUTHORIZATIONS

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

光知道角色有列权限没用，得知道当前会话或指定用户是否激活了该角色。MySQL 不自动展开角色链，ROLE_COLUMN_GRANTS 本身不包含用户信息。

实操建议：

查当前登录用户已激活的角色：SELECT * FROM INFORMATION_SCHEMA.APPLICABLE_ROLES
查某用户（比如 'dev_user'@'localhost'）被授予的所有角色（含未激活的）：
```
SELECT ROLE_NAME, IS_GRANTABLE
FROM INFORMATION_SCHEMA.ADMINISTRABLE_ROLE_AUTHORIZATIONS
WHERE GRANTEE = '''dev_user''@''localhost''';
```
注意引号要双写（MySQL 字符串转义规则）

把角色成员关系和列权限连起来查（示例：找所有能改 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 只会显示 GRANT r_w TO 'u'@'h'，不会告诉你 col_a 能改——这在排查「为什么 UPDATE 其他列成功、唯独这列报错」时就是盲区。

实操建议：

验证具体操作前，优先用 has_column_privilege() 类函数——但注意：MySQL **没有**内置的 has_column_privilege()；PostgreSQL 有，MySQL 没有等价函数
MySQL 中唯一可靠的运行时验证方式是：用目标用户账号实际连接，执行 SELECT ... FROM INFORMATION_SCHEMA.COLUMN_PRIVILEGES（查直授）或切换角色后查 ROLE_COLUMN_GRANTS（查角色授）
如果应用报 ERROR 1142 (42000): UPDATE command denied 且只发生在某列，90% 是列级权限问题，立刻跳转查 COLUMN_PRIVILEGES 和 ROLE_COLUMN_GRANTS，别在 SCHEMA_PRIVILEGES 里兜圈子

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

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 查到的权限也不会生效