在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里有记录，对应的权限也不会生效。
