列级select权限需先撤销表级权限才生效，字段名须严格匹配且不带前缀，join和子查询可绕过限制，生产环境应使用视图实现可靠字段隔离。
列级SELECT权限必须先撤销表级权限才生效
直接执行 GRANT SELECT(id, name) ON mydb.users TO 'u'@'%' 不会起作用，如果该用户已经拥有 SELECT ON mydb.users 或更宽泛的 SELECT ON mydb.* 权限。MySQL 的列级权限是“降级覆盖”，不是叠加限制——它只在没有更高粒度权限时才生效。
必须分两步操作：
- 先用
REVOKE SELECT ON mydb.users FROM 'u'@'%'清掉原有表级SELECT - 再执行
GRANT SELECT(id, name) ON mydb.users TO 'u'@'%'
漏掉第一步，后续所有列级授权都等于没设。别信“授了新权限就自动覆盖旧的”这种直觉。
字段名写法错误会导致授权静默失败
列级授权对字段名语法极其敏感，错一个字符就无效，且 MySQL 不报错，只会让你以为“权限生效了”，实际仍可查全表。
必须遵守这些规则：
- 字段名不能带库名或表名前缀（
users.id❌，id✅） - 不能用通配符
*（SELECT(*)语法错误） - 字段含空格、短横线等特殊字符，必须用反引号包裹（
GRANT SELECT(`user-id`, `full name`) ON mydb.users） - 大小写需与
SHOW COLUMNS FROM mydb.users输出完全一致（MySQL 默认不区分，但严格模式下可能影响）
JOIN 和子查询能绕过列级权限
这是最常被忽略的安全盲区：列级 SELECT(id, name) 只检查 SQL 中**直写的字段名**是否在白名单里，不做结果集过滤。只要用户对表有任意列的 SELECT 权限，就能构造语句把未授权字段拉出来。
以下语句都能成功执行：
-
SELECT u1.id, u2.phone FROM users u1 JOIN users u2 ON u1.id = u2.id—— 别名u2触发另一次权限校验，只要phone在任一列授权列表中（哪怕只授给别的用户），就可能泄露 -
SELECT id, (SELECT phone FROM users LIMIT 1) AS leak FROM users LIMIT 1—— 子查询独立校验，不继承外层字段限制 -
SELECT id, name FROM users WHERE phone LIKE '%123%'—— 如果误授了phone列，WHERE 就能用；但若没授，这句会直接报错ERROR 1142 (42000): SELECT command denied
视图才是可靠字段隔离方案
列级权限本质是弱防护，适合内部轻量约束；生产环境真正可控的字段隔离，只能靠视图。
正确做法是：
- 建视图：
CREATE VIEW safe_users AS SELECT id, name FROM users - 只授视图权限：
GRANT SELECT ON mydb.safe_users TO 'u'@'%' - 同时回收基表权限：
REVOKE SELECT ON mydb.users FROM 'u'@'%'
视图边界清晰，JOIN 和子查询无法穿透——除非你显式在视图定义里引用了敏感字段。另外注意：视图权限独立管理，即使基表权限被撤，只要视图权限还在，用户就能查。
真正难的是权限清理的完整性：一个用户可能通过角色、旧 GRANT、跨库同名用户等多种路径拿到隐性权限，SHOW GRANTS FOR 'u'@'%' 是唯一可信验证方式，别跳过这步。
