MySQL 8.0支持列级权限，但仅限SELECT、INSERT、UPDATE、REFERENCES四种操作；DELETE、ALTER等不支持列级授权，且列名必须显式指定、不可用通配符，授权后需新连接生效。
MySQL 8.0 支持列级别授权，但仅限 SELECT、INSERT、UPDATE、REFERENCES 四种权限
MySQL 8.0 确实支持按列授权，但不是所有权限都能细粒度到列——DELETE、ALTER、DROP 这类表级操作权限无法指定列。真正能加列名的只有 SELECT、INSERT、UPDATE 和 REFERENCES（后者极少用）。如果你试图对 DELETE 加列列表，MySQL 会直接报错：ERROR 1221 (HY000): Incorrect usage of column/field list。
常见错误是照着文档抄了语法却忽略权限类型限制，结果执行失败。实际使用中，最常落地的是 SELECT 和 UPDATE 列授权，比如给运维账号只查 id、created_at，不暴露 password_hash 或 email。
GRANT SELECT(id, name, created_at) ON db.users TO 'reporter'@'%';GRANT UPDATE(status, updated_at) ON db.users TO 'admin'@'localhost';- 不能写：
GRANT DELETE(email) ON db.users TO ...—— 语法非法
列授权必须配合具体列名，不能用 * 或通配符
MySQL 不允许在列权限中使用 *，哪怕你写 SELECT(*) 也会报错：ERROR 1064 (42000): You have an error in your SQL syntax。列名必须显式列出，且区分大小写（取决于表定义时的字符集和 lower_case_table_names 设置）。
典型误操作是想“授权除敏感列外的所有列”，结果发现没法用排除逻辑，只能白名单式列举。如果表字段多、变动频繁，列授权维护成本会明显上升——每次加字段都得同步更新 GRANT 语句。
- ✅ 正确：
GRANT SELECT(id, username, role) ON app.users TO 'api'@'10.0.0.%'; - ❌ 错误：
GRANT SELECT(*) ON app.users TO ... - ❌ 错误：
GRANT SELECT(id, *) ON app.users TO ... - 列名拼错（如写成
user_name而实际是username）会导致授权静默失败——用户查该列时直接报ERROR 1142 (42000): SELECT command denied
列权限叠加时，以最严格规则为准，且不继承表级权限
如果用户同时有表级 SELECT 和列级 SELECT(a,b)，那他只能查 a、b 列；反过来，如果只给了列级 SELECT(a)，即使没给表级权限，也仍可查 a 列。MySQL 的权限检查是“最小权限生效”，不是“取并集”。
这点容易被忽略：列权限不会自动覆盖或补充表级权限，而是独立校验。更麻烦的是，SHOW CREATE TABLE、DESCRIBE 这类元数据操作不受列权限控制——只要用户有表级 SELECT 或任意列 SELECT，就能看到整张表结构，包括未授权列名。
- 用户 A 有
SELECT ON db.t→ 可查所有列，也可DESCRIBE t - 用户 B 有
SELECT(col1) ON db.t→ 只能查 col1，但也同样能DESCRIBE t看到 col2、col3 - 撤销列权限需精确匹配：
REVOKE SELECT(col1) ON db.t FROM 'u'@'h';，不能只写REVOKE SELECT ON db.t—— 后者不触碰已授的列权限
列授权后必须 FLUSH PRIVILEGES 吗？
不需要。GRANT 语句本身会立即生效（前提是执行者有 GRANT OPTION），MySQL 8.0 的权限系统基于缓存，但 GRANT / REVOKE 会自动刷新对应用户的权限缓存。只有直接修改 mysql.columns_priv 表才需要手动 FLUSH PRIVILEGES，而这是不推荐的操作方式。
真正要注意的是连接复用：如果用户当前已有活跃连接，新授的列权限不会实时作用于该连接，要等其断开重连或执行 mysql_change_user()（如 PHP 的 mysqli::change_user()）。所以测试时别用长连接连着跑，否则会误判授权没生效。
- ✅ 授权后新开连接测试，结果可靠
- ⚠️ 复用旧连接查未授权列 → 报错，但不是权限没生效，是连接缓存旧权限
- 不要手动改
mysql.columns_priv表，风险高且易破坏权限一致性
列级授权在 MySQL 里是“功能可用但边界清晰”的设计：它解决的是明确的列隔离需求，而不是替代应用层字段过滤。一旦业务需要动态列控制（比如按角色配置可见字段），靠 GRANT 维护很快会变得脆弱——这时候该考虑在中间件或 ORM 层做字段裁剪，而不是堆更多 GRANT 语句。
