mysql支持列级权限，仅限select、insert、update和references四类操作且须显式指定列名；其他权限如delete、alter只能作用于整表。
MySQL 列级权限到底支不支持？
MySQL 本身支持列级权限（column-level privileges），但仅限于 SELECT、INSERT、UPDATE 和 REFERENCES 这四类操作，且必须显式指定列名——不能通配，也不能对视图或生成列授权。其他权限（如 DELETE、ALTER）只能作用于整张表。
怎么用 GRANT 给用户分配特定列的 SELECT 权限？
语法是 GRANT SELECT(col1, col2) ON db.table TO 'user'@'host'，注意括号里是列名列表，不是字符串。常见错误包括：
- 漏写数据库名或表名，导致报错
Error 1144 (42000): Wildcard denied for column grant - 对不存在的列授权，MySQL 不报错但后续查询会提示
Column 'xxx' in field list is ambiguous或直接拒绝访问 - 用户已有表级
SELECT权限，再授列级权限不会覆盖，而是叠加；但列级拒绝（REVOKE）只影响对应列，不影响其他列
示例：GRANT SELECT(id, name) ON test.users TO 'app_reader'@'10.0.1.%';
UPDATE 或 INSERT 列权限要注意什么？
这两类权限在实际使用中容易踩坑：
-
INSERT列权限要求：插入语句中所有被赋值的列都必须有权限，哪怕只插一列，其他列为 NULL 或默认值也不行 -
UPDATE列权限要求：UPDATE 子句中出现在SET右侧的列（即被修改的列）必须有权限；但WHERE中引用的列无需单独授权（只要能读取整行即可，不过若只有部分列 SELECT 权限，则 WHERE 用到无权列会报错） - 如果同时需要
SELECT某些列 +UPDATE其他列，必须分别授权，MySQL 不自动补全
例如：用户只有 UPDATE(status) 权限，执行 UPDATE orders SET status='shipped' WHERE id=123; 是允许的；但如果 WHERE id=123 中的 id 列没有 SELECT 权限，就会失败。
如何验证列权限是否生效？
别只看 SHOW GRANTS，它显示的是授权语句，不反映实际效果。更可靠的方式是切换用户后实测：
- 用
SELECT *查表会报错ERROR 1142 (42000): SELECT command denied to user ... for column 'xxx'（哪怕只少一个列权限） - 用
SELECT col1, col2只查已授权列，应成功 - 检查
information_schema.COLUMN_PRIVILEGES表，但注意该表只记录显式授予的列权限，不包含继承自表级权限的隐式访问
权限变更后记得执行 FLUSH PRIVILEGES;（仅当手动改了 mysql 系统表才需要；常规 GRANT 会自动生效）。
列级权限配置起来看似简单，但权限叠加逻辑、WHERE 子句列访问限制、以及错误信息不够直观，容易在上线后才发现数据查不到或更新失败。建议在测试环境用最小权限组合跑通完整业务 SQL 再部署。