MySQL支持列级权限，但仅限SELECT、INSERT、UPDATE、REFERENCES四类操作且须显式指定字段名；DELETE、ALTER、DROP等不支持列级授权，天然作用于整行或整表。
MySQL到底支不支持列级权限
支持，但仅限 SELECT、INSERT、UPDATE、REFERENCES 四类操作，且必须显式列出字段名；DELETE、ALTER、DROP 等操作天然作用于整行或整表，无法按列授权。
常见误解是“GRANT SELECT (id) ON db.tbl”能限制用户只看到 id 字段——它确实能，但前提是用户没有该表的全表 SELECT 权限。一旦授予过 GRANT SELECT ON db.tbl，列级限制即被覆盖，MySQL 会按高权限生效。
- 列级权限存储在
mysql.columns_priv表中，SHOW GRANTS只显示简化结果，查实际生效权限得执行：SELECT * FROM mysql.columns_priv WHERE User='u' AND Host='h' AND Db='db' AND Table_name='tbl';
-
Column_priv字段是逗号分隔字符串（如Select,Update），不是布尔值 - 手动 INSERT/UPDATE 过
mysql.columns_priv后，必须执行FLUSH PRIVILEGES;才生效
怎么正确授予列级 SELECT 权限
语法严格，括号不能省，列名不能用通配符，也不能混写全表与列级授权：
GRANT SELECT (id, name, email) ON mydb.users TO 'reporter'@'localhost';
错误写法示例（会报 ERROR 1064）：
GRANT SELECT (id), SELECT * ON mydb.users TO 'reporter'@'localhost';
- 用户账号必须已存在，否则报
ERROR 1133 (HY000): Can't find any matching row in the user table - 若用户已有
SELECT ON mydb.users，再授列级权限无效——需先REVOKE SELECT ON mydb.users FROM 'reporter'@'localhost'; - 应用层执行
SELECT *时，MySQL 会返回所有有SELECT权限的列，无权限列值为NULL，但字段名仍暴露（结构泄露）
UPDATE 或 INSERT 列权限为什么总失败
根本原因不是语法错，而是字段覆盖不全。例如只授了 UPDATE (status)，但 SQL 中写了 UPDATE users SET status='a', updated_at=NOW()，就会报 ERROR 1142 (42000): UPDATE command denied ... for column 'updated_at'。
-
INSERT ... VALUES要求所有非 NULL/DEFAULT 列都必须在授权范围内；推荐改用INSERT ... SET语法，只显式赋值已授权字段 -
UPDATE权限不控制读取——即使没授SELECT (updated_at)，只要授了UPDATE (updated_at)，语句就能执行（但读不到旧值） - ORM 或客户端工具自动拼接全字段时极易踩坑，列级权限难以维护，不适合动态字段场景
为什么生产环境更推荐用视图替代列级权限
因为列级权限元数据分散、易遗漏、难审计，且绕过成本极低：用户只要换条 SQL 就能直查原表，或通过 SELECT * 暴露未授权字段结构。
可靠做法是建安全视图并只授视图权限：
CREATE VIEW users_public AS SELECT id, name, email FROM users;
GRANT SELECT ON mydb.users_public TO 'app_user'@'%';
- 必须确保
app_user对原表users无任何权限（SHOW GRANTS FOR 'app_user'@'%'输出里不能出现users） - 视图定义必须显式列出字段，禁用
SELECT *，否则基表新增敏感列会自动透出 - 视图性能无额外开销，MySQL 查询时会重写为对基表的等价语句并优化执行
真正难的是权限收敛——你得确认所有路径（包括触发器、存储过程、备份账号）都没给原表留后门，这点比写对一条 GRANT 语句重要得多。
