MySQL列级权限仅在无表级SELECT权限时生效，否则被忽略；其易被JOIN、子查询绕过且不控元数据；安全方案是用视图封装+回收原表权限，配合行级过滤与动态脱敏逻辑。
MySQL列级权限能控制敏感字段访问，但必须先撤掉表级SELECT权限，否则直接失效；真正安全的方案是用视图封装+权限回收，而不是只靠GRANT列名。
列级SELECT权限为什么经常“不生效”
常见错误现象：ERROR 1142 (42000): SELECT command denied to user 'u'@'%' for column 'salary'，即使你执行的是SELECT name FROM users——因为WHERE或ORDER BY里用了未授权列（如WHERE dept = 'HR' ORDER BY salary），MySQL会检查所有涉及列的权限。
- 列级权限只在用户**没有整表SELECT权限**时才起作用；如果之前执行过
GRANT SELECT ON db.users TO 'u'@'%'，后续GRANT SELECT (id, name) ON db.users完全被忽略 - 必须显式
REVOKE SELECT ON db.users FROM 'u'@'%'，再重授列级权限 - 列名不能带库名或表名前缀，
GRANT SELECT (users.name)是错的，应写GRANT SELECT (name) - 特殊字符列名（如
user-id）必须用反引号：GRANT SELECT (`user-id`, `full name`) ON db.users
为什么JOIN和子查询会绕过列级权限
列级权限只限制“直查字段”，不拦截间接访问。例如用户只有SELECT (id, name)权限，仍可执行：
SELECT u1.id, u2.phone FROM users u1 JOIN users u2 ON u1.id = u2.id;
或
SELECT id, (SELECT phone FROM users LIMIT 1) AS leaked FROM users LIMIT 1;
- 只要对
users表有任意列的SELECT权限，JOIN/子查询就能把未授权字段拉出来 - SHOW COLUMNS、DESCRIBE等元数据命令也不受列级权限约束，字段结构完全暴露
- 客户端工具（DBeaver、Navicat）或ORM常发
SELECT *，MySQL返回所有“有权限列”，无权限列值为NULL，但字段名和顺序仍可见
用视图替代列级GRANT才是可靠做法
视图把字段投影固化，权限边界清晰，且能叠加行级过滤逻辑。关键操作步骤：
- 建视图只暴露安全字段：
CREATE VIEW safe_users AS SELECT id, name, dept, join_date FROM users; - 确保视图定义中不包含敏感字段（如
salary、phone），也不调用加密函数（如AES_DECRYPT()）——那属于应用层职责 - 给用户只授视图权限：
GRANT SELECT ON db.safe_users TO 'report_user'@'%'; - 立刻回收原表权限：
REVOKE SELECT ON db.users FROM 'report_user'@'%'; - 验证是否生效：
SHOW GRANTS FOR 'report_user'@'%';，确认输出里没有ON db.users
列级权限和视图组合使用的注意事项
两者可以共存，但优先级和维护成本差异大：
- 列级权限元数据存在
mysql.columns_priv表里，主从同步、备份恢复、权限迁移时容易遗漏，需手动FLUSH PRIVILEGES - 视图定义本身不带权限，但
SQL SECURITY DEFINER可配合行级过滤（如加WHERE business_user_id = (SELECT ... FROM user_role_mapping WHERE db_user = CURRENT_USER())） - 如果业务需要动态脱敏（比如HR能看到完整手机号，普通员工只能看
138****1234），必须用视图+CASE表达式，不能依赖列权限 - 真正难的不是语法，而是把“谁该看到哪些字段”这个业务规则，稳定映射到视图定义或权限分配流程中——一旦规则变，所有相关视图和GRANT都要同步更新
