mysql列级权限仅支持select、insert、update、references四种操作，delete等行级操作不支持列粒度控制；授权时列名错误会静默成功但后续查询报列不存在，而非权限拒绝。
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'@'%'，其中 email 列实际不存在，语句仍成功返回，但后续用户执行 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 都可能让列级权限形同虚设。
