能生效，但需先撤销表级SELECT权限；列级SELECT仅在无更高粒度权限时起作用，且不阻止JOIN或子查询间接读取未授权列。
GRANT SELECT(id, name) 语法是否生效
能生效，但前提是用户没有更高粒度的权限覆盖它。MySQL 的列级 SELECT 权限只在用户**未被授予整张表的 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 是错的），也不能用通配符 *。
列级权限不阻止 JOIN 或子查询间接读取敏感字段
这是最容易被忽略的安全盲区。列级 SELECT(id, name) 只限制对 mydb.users 表的直接字段访问，但用户仍可构造如下语句绕过：
SELECT u1.id, u2.phone FROM users u1 JOIN users u2 ON u1.id = u2.id;
只要用户对 users 表有任意列的 SELECT 权限，JOIN 就可能把未授权字段（如 phone）拉出来。同理，(SELECT phone FROM users LIMIT 1) 这类子查询也照常执行。
本质是 MySQL 列级权限仅做“直查字段白名单”，不做“结果投影过滤”。真实场景中，应优先考虑视图隔离：
- 建视图：
CREATE VIEW safe_users AS SELECT id, name FROM users; - 授视图权限：
GRANT SELECT ON mydb.safe_users TO 'u'@'%' - 同时
REVOKE SELECT ON mydb.users—— 视图才是可控边界
哪些字段类型或操作不支持列级控制
MySQL 仅对 SELECT 和 REFERENCES 支持列级权限；其他所有 DML 操作都不行：
-
INSERT、UPDATE、DELETE只能按表级授权，无法限制“只能 INSERT name 字段” - 即使你只给
UPDATE(email)，用户执行UPDATE SET password='x' WHERE id=1仍会报错，因为没授password列权限；但若已授整表UPDATE，列级授权就完全失效 -
SHOW COLUMNS FROM users这类元数据操作不受列级权限约束，用户仍能看到所有字段定义
另外，列名含特殊字符（如空格、短横线）必须用反引号包裹：GRANT SELECT(`user-id`, `full name`) ON mydb.users。
验证列级权限是否真正生效
别信 SHOW GRANTS 输出里有没有列名——它只反映 GRANT 语句字面内容，不反映实际叠加效果。必须登录该用户实测：
- 执行
SELECT * FROM mydb.users→ 应报错ERROR 1142 (42000): SELECT command denied（因*触发未授权列） - 执行
SELECT id, name FROM mydb.users→ 应成功 - 执行
SELECT id, phone FROM mydb.users→ 应报同样错误 - 执行
SELECT COUNT(*) FROM mydb.users→ 成功（聚合函数不依赖具体列权限）
特别注意：如果测试时复用旧连接，权限变更可能未生效，务必用新会话重连。host 匹配也要精确——'u'@'192.168.1.%' 和 'u'@'192.168.1.100' 是两条独立权限记录。
