MySQL原生不支持真正列级权限，GRANT SELECT(col)仅对显式列名查询生效，易被SELECT*或视图绕过；可靠方案是创建显式字段视图、单独授权并禁用SHOW VIEW。
MySQL 原生不支持真正意义上的“列级权限”抽象层，GRANT SELECT (col1, col2) 这类语法虽能执行，但行为受限、易被绕过，且不覆盖所有操作场景。它不是“字段白名单”，而是“字段显式授权叠加器”，必须配合严格约束才勉强可用。
GRANT SELECT (col) 为什么查不到数据？
列级 SELECT 权限只在你**显式列出被授权列**时生效，哪怕只多写一个未授权列，整条语句就失败：
-
SELECT id, name FROM users;✅ —— 两列都在GRANT SELECT (id, name)中 -
SELECT id, name, email FROM users;❌ ——email未授权，报ERROR 1142 -
SELECT * FROM users;❌ ——*展开后含未授权列，直接拒绝 -
SELECT name FROM users WHERE email = 'a@b.c';❌ ——WHERE引用未授权列，解析阶段就拦截
注意：用户必须**没有表级 SELECT 权限**，否则列级限制形同虚设——高权限覆盖低权限。
INSERT 和 UPDATE 列权限的隐性陷阱
这两类权限不是“允许插入/修改这些列”，而是“只允许你在语句中显式操作这些列”，且校验极严：
-
GRANT INSERT (name, email) ON users TO 'u'@'%';后：
→INSERT INTO users (name, email) VALUES ('x', 'y');✅
→INSERT INTO users VALUES ('x', 'y', NOW());❌（字段数不匹配 + 第三列未授权）
→INSERT INTO users SET name='x', email='y';✅（推荐用SET语法，更安全） -
GRANT UPDATE (status) ON orders TO 'u'@'%';后：
→UPDATE orders SET status = 'done' WHERE id = 123;❌ ——WHERE id引用未授权列，直接报错
→ 必须改写为UPDATE orders SET status = 'done' WHERE status = 'pending';或其他已授权列做条件
为什么视图比 GRANT (col) 更可靠？
因为 GRANT SELECT (col) 无法阻止客户端发 SELECT *，也无法防御 ORM 自动生成全字段查询；而视图是物理隔离层：
- 必须显式写字段：
CREATE VIEW v_users_pub AS SELECT id, username, created_at FROM users;—— 绝不用* - 视图权限独立：
GRANT SELECT ON mydb.v_users_pub TO 'u'@'%';，和基表权限完全解耦 - 必须禁用元数据泄露：
REVOKE SHOW VIEW ON *.* FROM 'u'@'%';，否则SHOW CREATE VIEW会暴露字段逻辑 - 基表加新列不影响视图，但删了视图里引用的列会导致下次查询直接报
ERROR 1054
列权限真正生效前必须确认的三件事
很多人授完权却无效，问题往往出在基础匹配上：
- 账号
'u'@'host'必须和连接时实际使用的 host 字符串**完全一致**——'u'@'10.20.%'不匹配 DNS 解析出的'u'@'pod-123.svc.cluster.local' - 列权限存于
mysql.columns_priv表，SHOW GRANTS只显示摘要，要确认细节得查该表：SELECT * FROM mysql.columns_priv WHERE User='u' AND Host='%' AND Db='mydb' AND Table_name='users'; - 已建立的连接不会自动刷新权限，新权限只对新建连接生效；若测试时复用旧连接，会误判为授权失败
列权限本质是“窄通道”，不是“防火墙”。真要防 AI 或第三方工具乱读敏感字段，优先走视图+禁 SHOW VIEW，别依赖 GRANT SELECT (ssn) —— 它太容易被绕过了。
