MySQL列级权限仅支持SELECT、INSERT、UPDATE、REFERENCES，需在GRANT中用括号指定列名，不可混用全列与列级授权；其生效受限于直接表访问，视图/存储过程/触发器可能绕过。
MySQL 支持列级别权限，但仅限于 SELECT、INSERT、UPDATE、REFERENCES
MySQL 确实允许对单个字段（列）授予权限，但不是所有权限类型都支持。只有 SELECT、INSERT、UPDATE 和 REFERENCES 可以细化到列；DELETE、DROP、ALTER 等操作天然作用于整张表，无法按列授权。
语法上，列名必须写在括号里，紧跟在表名之后：
GRANT SELECT (id, name) ON mydb.users TO 'alice'@'localhost';
注意：GRANT 语句中不能混用“全列授权”和“指定列授权”。比如下面这句是非法的：
GRANT SELECT (id), INSERT ON mydb.users TO 'bob'@'%'; -- ❌ 错误：INSERT 没指定列，且与 SELECT 列混写
UPDATE 和 INSERT 的列权限有隐含约束
UPDATE 列权限只控制哪些字段能被修改，但不阻止其他字段被读取（读取仍需 SELECT 权限）。同样，INSERT 列权限只允许向指定列插入值，但如果你 INSERT 时没提供值（比如用 DEFAULT 或允许 NULL），MySQL 会检查你是否有该列的 INSERT 权限——哪怕没显式赋值。
- 想让用户只能更新
status字段？得单独给UPDATE (status)，同时确保不授予整表UPDATE - 如果用户有
INSERT (name, email)权限，却执行INSERT INTO users VALUES (1, 'x', 'y', 'z')（4 列），会报错：ERROR 1105 (HY000): Column count doesn't match value count at row 1—— 实际错误来自字段数不匹配，但根本原因是第 4 列（比如created_at）不在授权范围内，MySQL 拒绝整条语句 -
INSERT ... SET语法更安全，推荐用：INSERT INTO users SET name='a', email='b'
SHOW GRANTS 不直接显示列级细节，得查 mysql.columns_priv
执行 SHOW GRANTS FOR 'alice'@'localhost' 通常只显示类似 GRANT SELECT (id,name) ON `mydb`.`users`...，但实际权限是否生效、有没有被更细粒度的拒绝规则覆盖，得查系统表：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SELECT * FROM mysql.columns_priv WHERE User='alice' AND Host='localhost' AND Db='mydb' AND Table_name='users';
注意三点：
- 该表内容不会实时反映在
SHOW GRANTS中，需执行FLUSH PRIVILEGES后才生效（尤其手动 INSERT/UPDATE 过mysql.columns_priv） -
Column_priv字段是逗号分隔字符串，如Select,Update，不是布尔值 - 列权限优先级高于表级权限，但低于显式的
DENY（MySQL 本身不支持 DENY 语法，这点和 SQL Server 不同；所谓“拒绝”只能靠不授权+权限最小化实现）
常见失效场景：视图、存储过程、触发器绕过列权限
列权限只在直接访问基表时生效。一旦用户通过视图查询，权限检查对象变成视图定义者（DEFINER）的权限，而不是调用者的列权限。同理，存储过程中执行的 UPDATE 语句，也以 DEFINER 权限运行，可能修改未授权的列。
所以如果你依赖列权限做数据隔离，要注意：
- 避免给用户
CREATE VIEW权限，否则他们可自己建视图绕过限制 - 存储过程不要用
SQL SECURITY DEFINER，除非你明确信任其逻辑；建议用SQL SECURITY INVOKER，这样过程内 DML 也会受调用者列权限约束 - 触发器始终以 DEFINER 权限执行，无法被调用者列权限限制 —— 这是最容易被忽略的一环
列权限不是银弹，它只管“用户直连表时怎么操作”，不管间接路径。真要强隔离，得结合应用层过滤或行级安全（MySQL 8.0+ 的 CREATE POLICY 配合角色和函数，但列级策略仍需自己编码兜底）。
