grant语句必须严格按语法写，列级select权限需括号紧贴权限名且列名用英文逗号分隔无空格；insert/update列权限需覆盖语句中所有显式或隐式涉及的列；撤销时revoke必须与原grant完全一致。
GRANT 语句能直接给用户分配特定表的某一列权限，但必须严格按语法写，漏一个字符或括号位置错都会失败。
列级 SELECT 权限怎么写才有效
核心是括号必须紧贴权限名，且列名之间用英文逗号分隔，不能加空格或引号：GRANT SELECT(id, name) ON db.table TO 'user'@'host';
- 错误写法：
GRANT SELECT (id, name)（括号前多空格）、GRANT SELECT('id','name')（加单引号）、GRANT SELECT(id,name) ON table（漏数据库名） - 漏写数据库名或表名会报错：
ERROR 1144 (42000): Wildcard denied for column grant - 对不存在的列授权不会报错，但后续查询该列时直接拒绝，错误信息可能是：
Column 'xxx' in field list is ambiguous或更模糊的访问拒绝 - 如果用户已有表级
SELECT权限，再授列级权限会覆盖——最终只允许查你列出的那些列，其他列查不到
INSERT 和 UPDATE 列权限的实际约束
这两类权限比 SELECT 更容易踩坑，因为 MySQL 会检查语句中“出现”的每一列是否都有对应权限。
-
INSERT：所有被显式赋值的列，以及所有未赋值但有默认值/允许 NULL 的列，都必须在授权列表里。比如授了INSERT(name, email)，却执行INSERT INTO t VALUES ('a', 'b', NOW())（三列），哪怕第三列是函数生成，也会因列数不匹配被拒 -
UPDATE：只检查SET后面的列，WHERE里的列不需UPDATE权限，但必须有SELECT权限——否则WHERE id=123会因无法读取id列而失败 - 不能混授：
GRANT SELECT(id), INSERT ON db.t TO 'u'@'h'是非法语法，MySQL 直接报错
怎么确认列权限真生效了
SHOW GRANTS 只显示授权语句，不反映实际效果。验证必须切换用户实测：
- 用
SELECT *查表，只要缺一个列权限，就报：ERROR 1142 (42000): SELECT command denied to user for column 'xxx' - 只查已授权列，如
SELECT id, name，应成功返回 - 查系统表
information_schema.COLUMN_PRIVILEGES能看到显式授予的记录，但注意它不包含从表级继承来的隐式权限 - 权限变更后不用
FLUSH PRIVILEGES——GRANT本身已实时写入系统表并生效
撤销列权限时最容易忽略的一点
用 REVOKE 撤销列权限，必须和原 GRANT 完全一致：相同权限类型、相同列列表、相同数据库名和表名、相同用户名和主机段。
- 比如用
GRANT SELECT(id, name) ON db.t TO 'u'@'h'授的权，就得用REVOKE SELECT(id, name) ON db.t FROM 'u'@'h'撤；只写REVOKE SELECT ON db.t FROM 'u'@'h'不会撤掉列级权限 - 表级和列级权限是独立存储的，
REVOKE SELECT ON db.t不会影响之前单独授的SELECT(col) - 权限叠加逻辑很隐蔽：先给全表
SELECT，再给单列SELECT(col)，后者会生效；反过来，先列后全表，全表授权会把列限制冲掉
