MySQL 8.0+ 支持列级权限，仅对 SELECT、INSERT、UPDATE、REFERENCES 生效，需显式授权如 GRANT SELECT(col1) ON db.tbl；不带列名的授权会覆盖列级权限，且字段变更后权限不自动迁移。
MySQL 8.0+ 列级权限到底能不能用？
能，但只对 SELECT、INSERT、UPDATE、REFERENCES 四种操作生效，且必须显式授权——GRANT SELECT(col1) ON db.tbl TO 'user'@'%' 这种写法才管用。不带列名的 GRANT SELECT ON db.tbl 会覆盖掉之前所有列级授权，这是最常踩的坑。
常见错误现象：SELECT * 返回 NULL 或报错 Column 'xxx' is not in the result set（实际是权限拒绝，不是字段不存在）；而单独查某列却能返回值，说明列级权限已生效但被其他规则干扰。
- MySQL 5.7 及更早版本不支持列级权限，
GRANT ... (col)语法会被忽略，不报错也不生效 - 列权限和表权限共存时，只要任一列没授权，
SELECT *就会失败（哪怕其他列都开了） -
UPDATE列权限只控制“能否改这个字段”，不影响 WHERE 条件里是否能引用该字段（WHERE 不受列权限限制）
怎么查用户当前对某字段有没有权限？
别信 SHOW GRANTS 的输出——它默认只显示表级授权，列级权限藏在系统表里。直接查 information_schema.COLUMN_PRIVILEGES 最可靠：
SELECT COLUMN_NAME, PRIVILEGE_TYPE, IS_GRANTABLE FROM information_schema.COLUMN_PRIVILEGES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table' AND COLUMN_NAME = 'sensitive_col' AND GRANTEE = "'user'@'%'"
注意：GRANTEE 字段值带单引号和 @ 符号，必须完全匹配（包括引号），否则查不到。
- 如果结果为空，说明没授过列权限，或授权对象写错了（比如用了
'user'@'localhost'却从远程连） -
IS_GRANTABLE = 'YES'表示用户还能把这列权限转授给别人，生产环境建议设为NO - 该视图不反映动态权限（如
ROLE继承来的），得结合ROLE_ROUTINE_GRANTS等查角色链
为什么加了列权限还是查不到？三个隐蔽原因
列权限只是其中一环，下面这些机制会优先拦截请求：
- 行级安全策略（
CREATE POLICY）：即使列有权限，策略返回 FALSE 也会过滤整行 - 视图定义里的字段别名或计算逻辑：如果视图基于原表但重命名了字段，列权限仍按原字段名判定，不是别名
- 代理用户（
PROXY）权限：被代理用户（DEFINER）的列权限不自动继承，需单独授权给代理用户
典型场景：用 mysqldump 导出表时失败，提示某列无权限——其实是因为 dump 默认走 SELECT *，而你只给了部分列的 SELECT 权限。解决办法是显式指定字段：mysqldump --fields-enclosed-by='"' -u user -p db tbl --columns=col1,col2。
ALTER TABLE 修改字段后列权限还有效吗？
无效。MySQL 不会自动迁移列级权限。字段重命名、删除、类型变更都会导致原有 COLUMN_PRIVILEGES 记录失效（记录保留但不再匹配）。
- 重命名字段：旧字段名的权限记录还在，但新字段名没权限，需手动补
GRANT SELECT(new_col) ... - 删字段再加同名字段：看起来名字一样，但内部
column_id已变，权限不继承 - 用
ALTER TABLE ... CHANGE时，哪怕只是改大小写（如name→Name），在严格模式下也视为新字段
复杂点在于：权限丢失不会报错，只是静默拒绝访问。上线前务必用真实账号跑一遍字段级查询验证，不能只靠 DDL 脚本检查。
