MySQL列级SELECT权限仅在无更高粒度权限时生效，需先撤销表级权限；字段名不可带前缀或通配符，特殊字符须加反引号；列级权限无法阻止JOIN和子查询绕过；INSERT/UPDATE支持列级授权但受表级权限压制，DELETE不支持；推荐使用视图+权限隔离实现可靠字段控制。
列级 SELECT 权限必须先撤销表级权限才生效
直接执行 GRANT SELECT(id, name) ON mydb.users TO 'u'@'%' 不会起作用，如果用户 already 有 SELECT ON mydb.users 全表权限。MySQL 的列级权限是“降级覆盖”，不是“叠加限制”——它只在没有更高粒度权限时才生效。
必须分两步操作：
- 先用
REVOKE SELECT ON mydb.users FROM 'u'@'%'清掉原有表级 SELECT - 再执行
GRANT SELECT(id, name) ON mydb.users TO 'u'@'%' - 注意字段名不能带库或表前缀（
users.id错，id对），也不能用通配符* - 字段含特殊字符（如
user-id、full name）必须用反引号：GRANT SELECT(`user-id`, `full name`) ON mydb.users
列级权限挡不住 JOIN 和子查询绕过
即使只授了 SELECT(id, name)，用户仍可能把未授权字段（比如 phone、salary）拉出来。MySQL 不做结果集过滤，只检查 SQL 中直写的字段名是否在白名单里。
这些语句都能成功执行：
-
SELECT u1.id, u2.phone FROM users u1 JOIN users u2 ON u1.id = u2.id—— 只要对users有任意列 SELECT 权，JOIN 就能跨别名暴露字段 -
SELECT id, (SELECT phone FROM users LIMIT 1) AS leak FROM users LIMIT 1—— 子查询独立校验权限，不继承外层字段限制 -
SELECT id, name FROM users WHERE phone LIKE '%123%'—— WHERE 中引用未授权列，只要该列在白名单里就允许（但这里phone不在白名单，会报错；但如果误授了phone，WHERE 就能用）
INSERT/UPDATE 支持列级，DELETE 不支持
MySQL 确实允许对 INSERT 和 UPDATE 做列级授权，但仅限语法层面有效，且行为容易误判：
-
GRANT INSERT(name, email) ON mydb.users TO 'u'@'%'—— 用户执行INSERT INTO users (name, email) VALUES ('a','b')成功，但INSERT INTO users SET password='x'会报错（因没授password列） -
GRANT UPDATE(email) ON mydb.users TO 'u'@'%'—— 用户可执行UPDATE users SET email='x' WHERE id=1，但UPDATE users SET email='x', password='y'会拒绝（哪怕password列本身没被修改） -
DELETE没有列级权限——要么能删整行，要么不能删。试图GRANT DELETE(id) ON ...会报语法错误 - 所有列级 DML 权限都受表级权限压制：如果用户已有
INSERT ON mydb.users，再授列级INSERT(name)完全无效
真正可控的替代方案是视图 + 权限隔离
列级权限本质是弱约束，生产环境应优先用视图作为权限边界：
- 建视图：
CREATE VIEW safe_users AS SELECT id, name, created_at FROM users - 撤原表权限：
REVOKE SELECT ON mydb.users FROM 'u'@'%' - 授视图权限：
GRANT SELECT ON mydb.safe_users TO 'u'@'%' - 视图屏蔽了底层表结构，JOIN 或子查询无法穿透到原表字段；用户查
safe_users只能看到定义好的三列，且无法通过SHOW CREATE VIEW推断原表敏感字段（除非你显式授了SHOW VIEW） - 注意：视图依赖的原表权限必须由定义者（DEFINER）持有，建议用高权限账号创建，并设
SQL SECURITY DEFINER
视图不是银弹——它不阻止用户通过其他已授权表做关联推断，但至少把字段暴露面收窄到明确声明的投影结果上。这点比列级权限可靠得多。
