MySQL能否为用户分配具体的列级权限？

本文共计916个文字，预计阅读时间需要4分钟。

可以，但限制非常具体：

常见误判是以为 GRANT ... ON table(col1, col2) 能覆盖所有权限类型，实际会报错：

ERROR 1221 (HY000): Incorrect usage of COLUMN GRANT and NON-COLUMN PRIVILEGES

• SELECT 列权限：控制哪些列能被 SELECT 查询到（注意：若用户有表级 SELECT，列权限会被绕过）
• INSERT 列权限：控制 INSERT INTO t(c1,c2) VALUES(...) 中能显式指定哪些列；但若用 INSERT INTO t VALUES(...)（无列名），则需所有列都有 INSERT 权限才允许
• UPDATE 列权限：只影响 SET col = ... 中被修改的列，未授权的列即使出现在 SET 子句中也会报错

列权限必须和表级权限共存，且优先级低于表级权限

这是最容易踩的坑：如果用户已有表级 SELECT 权限，再单独 revoke 某列的 SELECT，不会生效。列权限只在用户**没有对应表级权限**时起作用。

换句话说，列权限是“补充性限制”，不是“独立访问控制”。典型设计逻辑是：

• 先收回表级 SELECT：REVOKE SELECT ON db.t FROM 'u'@'%';
• 再授予特定列：GRANT SELECT(col1, col2) ON db.t TO 'u'@'%';
• 这样用户才能查 col1 和 col2，但查 col3 或 SELECT * 会报错 ERROR 1142 (42000): SELECT command denied to user

检查当前列权限可用：SELECT * FROM mysql.columns_priv WHERE User='u' AND Host='%' AND Db='db' AND Table_name='t';（需有 SELECT 权限查 mysql 系统库）

INSERT/UPDATE 列权限对 SQL 写法敏感，容易因语法触发拒绝

列权限不是“数据可见性控制”，而是“语句合法性校验”。它在 SQL 解析阶段就检查，不依赖运行时值。

• INSERT INTO t(col1,col3) VALUES(1,2)：只要用户有 col1 的 INSERT 权限，col3 没有也报错
• UPDATE t SET col1=1, col4=2 WHERE id=1：哪怕 col4 实际没被更新（比如 WHERE 不匹配），只要语句里写了，且用户无 col4 的 UPDATE 权限，就拒绝
• INSERT INTO t SELECT col1,col2 FROM other_t：这种写法不走列权限检查（因为目标列由源表决定），而是看用户对 other_t 的 SELECT 权限

列权限无法解决敏感字段脱敏或动态行过滤问题

列权限只能控制“能否在 SQL 中提到该列”，不提供任何数据层面的过滤、掩码或条件拦截能力。比如：

• 不能让 phone 列对普通用户显示为 ***-****-1234
• 不能实现“用户只能查自己部门的数据”（那是行级安全策略，MySQL 原生不支持，需应用层或视图+权限组合模拟）
• 不能阻止用户通过 JOIN + CONCAT 等方式间接推断被屏蔽列的值

真正需要列级数据管控时，更可行的路径是：建视图（CREATE VIEW v AS SELECT col1,col2 FROM t），然后只给用户视图的 SELECT 权限——既简洁，又避免列权限的语义歧义和维护复杂度。