能，但需确保用户未被授予整表SELECT权限，否则列级权限被覆盖；必须用GRANT SELECT(id,name) ON db.table显式授权，字段名不带前缀、不支持通配符；视图封装才是生产环境推荐的可靠方案。
列级 SELECT 权限能直接生效吗
能，但前提是用户没有更宽泛的权限覆盖它。MySQL 的列级 SELECT(id, name) 只在用户未被授予整张表的 SELECT 权限时才起作用。如果已执行过 GRANT SELECT ON mydb.users TO 'u'@'%'，再补一句 GRANT SELECT(id, name) ON mydb.users 完全无效——原权限依然允许查所有字段。
必须先清理：
REVOKE SELECT ON mydb.users FROM 'u'@'%'GRANT SELECT(id, name) ON mydb.users TO 'u'@'%'
注意：字段名不能带库名或表名前缀（users.id 错，id 对），也不能用通配符 *；含空格或短横线的字段需用反引号，如 `user-id`。
为什么查了非授权字段却不报错
常见现象：用户执行 SELECT * FROM users 却只返回 id 和 name，看似“成功限制”；但一写 SELECT id, phone FROM users 就报错 ERROR 1142。这不是 MySQL 过滤了结果，而是服务端在解析阶段就拒绝了含未授权字段的语句。
本质是语法校验，不是运行时过滤。所以：
- 字段白名单只作用于直查（
SELECT ... FROM users） - 不阻止
JOIN、子查询、UNION等间接读取方式 - 例如：
SELECT u1.id, u2.phone FROM users u1 JOIN users u2 ON u1.id = u2.id—— 只要用户对users有任意列SELECT权限，这条就能跑通
视图才是实际可用的字段隔离方案
列级权限本质是弱防护，真实生产环境应优先用视图。它把字段裁剪和行过滤都固化在定义里，权限边界清晰可控。
操作步骤：
- 建视图：
CREATE VIEW safe_users AS SELECT id, name, email FROM users WHERE status = 'active' - 撤回原表权限：
REVOKE SELECT ON mydb.users FROM 'u'@'%' - 只授视图权限：
GRANT SELECT ON mydb.safe_users TO 'u'@'%'
好处不止于字段控制：视图可加 WHERE 过滤行、可隐藏敏感逻辑、可跨库聚合、且权限独立于基表——这才是可交付的最小权限实践。
元数据和 DML 操作不受列级权限约束
列级 SELECT 权限不影响以下行为：
-
SHOW COLUMNS FROM users或DESCRIBE users：用户仍能看到所有字段定义 -
INFORMATION_SCHEMA查询：只要用户有任意表SELECT权限，就能查TABLES、COLUMNS表推断结构 -
INSERT/UPDATE/DELETE：完全不支持列级控制。哪怕只授了UPDATE(name)，用户一旦有整表UPDATE权限，就能改任意字段
真正需要字段级写入控制时，只能靠应用层拦截或触发器兜底，MySQL 原生不提供该能力。
