MySQL 列级权限只支持 SELECT、INSERT、UPDATE、REFERENCES 四种操作
MySQL 的列级（column-level）权限不是全功能的，它不能对 DELETE、TRUNCATE 或 ALTER 等语句生效——这些操作天然作用于整行，无法按列限制。真正能按列授权的只有：
SELECT（查特定列）、
INSERT（插特定列）、
UPDATE（改特定列）、
REFERENCES（外键引用时指定列）。其他权限即使写上列名，MySQL 也会忽略列粒度，降级为表级权限。
实操建议：
用GRANT SELECT (col1, col2) ON db.tbl TO 'u'@'h'授权列查询，注意括号内是列名列表，不是字符串
INSERT和
UPDATE授权时，必须显式列出允许操作的列；如果省略列名（如
GRANT INSERT ON db.tbl...），就变成整表插入权限 执行后务必运行
FLUSH PRIVILEGES，否则权限不立即生效（尤其在非
--skip-grant-tables模式下） 列级权限和表级权限共存时，MySQL 取“并集”逻辑：只要任一权限允许某列的操作，该操作即被允许
GRANT 语句中列名写错或不存在会静默失败
MySQL 不会在
GRANT语句中校验列是否存在。例如对一张只有
id和
name的表执行：
GRANT SELECT (id, email) ON test.users TO 'reader'@'%'，其中
SELECT email FROM test.users会直接报错
Unknown column 'email' in 'field list'，而非权限拒绝。
排查与规避方法：
授权前先查表结构：DESCRIBE test.users或
SHOW COLUMNS FROM test.users用
SELECT * FROM information_schema.COLUMNS WHERE TABLE_SCHEMA='test' AND TABLE_NAME='users'核对列名拼写（注意大小写敏感性，取决于
lower_case_table_names设置） 不要依赖错误提示反推权限问题——先确认列存在，再确认权限是否授予
列级权限无法通过 mysql.db 或 mysql.tables_priv 表直接管理
MySQL 的权限元数据分散在多个系统表中：
mysql.columns_priv才是存储列级权限的唯一位置。而
mysql.db（数据库级）、
mysql.tables_priv（表级）完全不包含列信息。直接往这些表里 INSERT 权限记录不会生效，且可能破坏权限一致性。
正确做法始终是使用
GRANT/
REVOKE语句：
GRANT UPDATE (status, updated_at) ON app.orders TO 'worker'@'10.0.1.%'; REVOKE UPDATE (created_at) ON app.orders FROM 'worker'@'10.0.1.%';
如果需要批量生成授权语句，可基于
information_schema.COLUMNS构造 SQL，但最终仍要靠
GRANT执行，不能绕过权限系统直写系统表。
列级权限在视图或存储过程中可能被绕过
列级权限只作用于直接访问基表的语句。如果用户有权限执行某个
VIEW或
STORED PROCEDURE，而该对象内部查询了被限制的列，MySQL 默认不会再次检查列权限（除非启用
SQL SECURITY DEFINER并由高权限用户定义）。这意味着列级权限不是绝对隔离屏障。
关键限制点：
视图默认以SQL SECURITY INVOKER运行，会继承调用者的列级权限 —— 这是安全的，但容易被忽略 若视图设为
SQL SECURITY DEFINER，且定义者拥有全列权限，则调用者可通过视图读取本无权访问的列 存储过程同理：过程内
SELECT *可能暴露受限列，且过程执行权限（
EXECUTE）本身不校验列级规则 所以列级授权必须配合对象权限审计：检查谁有
SELECT视图权限、谁定义了高权限过程
细粒度控制真正在意的是数据可见性，而不是语法层面的“禁止写列名”。列名写错、视图穿透、应用层拼接 SQL 都可能让列级权限形同虚设。
