不能。视图仅是逻辑封装，不自动隐藏字段；必须显式列出所需字段、撤回基表SELECT权限、仅授予视图权限，并禁用系统表访问，三者协同才有效防护。
视图能真正隐藏敏感字段吗
不能。视图只是逻辑层的查询封装，SELECT * 仍可能暴露字段；权限控制必须配合底层表权限 + 视图定义 + 用户角色三者协同。单纯建个视图不设权限，DBA 或有 SELECT 权限的用户仍可绕过视图直接查原表，甚至用 pg_views（PostgreSQL）或 INFORMATION_SCHEMA.VIEWS 查到视图定义里没选哪些字段。
关键点在于：视图本身不加密、不过滤数据行，只改变「默认可见列集」。它起作用的前提是——用户**没有对基表的直接访问权限**。
创建薪资视图时必须避开的三个陷阱
- 忘记显式列出字段：用
SELECT * FROM employees 建视图，一旦源表加了 bonus 或 stock_options 字段，视图自动包含，后续权限失控
- 没撤回基表权限：即使建了
emp_public_view，若用户仍有 SELECT on employees，SELECT salary FROM employees 一行就破防
- 视图定义含子查询或函数泄露：比如
COALESCE(salary, 0) 虽隐藏 NULL，但值本身未脱敏；更危险的是在视图里调用 pg_sleep() 类函数，可能被用于侧信道探测
SELECT * FROM employees 建视图，一旦源表加了 bonus 或 stock_options 字段，视图自动包含，后续权限失控 emp_public_view，若用户仍有 SELECT on employees，SELECT salary FROM employees 一行就破防 COALESCE(salary, 0) 虽隐藏 NULL，但值本身未脱敏；更危险的是在视图里调用 pg_sleep() 类函数，可能被用于侧信道探测 正确做法是：只写明需要暴露的字段，如 id, name, department, hire_date；建完立刻执行 REVOKE SELECT ON employees FROM junior_analyst。
PostgreSQL 中限制视图字段访问的最小可行配置
以 PostgreSQL 为例（MySQL 不支持行级/列级权限原生隔离，需靠应用层补位）：
CREATE VIEW emp_public AS SELECT id, name, department, hire_date FROM employees;
然后分两步收口：
-
REVOKE SELECT ON employees FROM junior_analyst; -
GRANT SELECT ON emp_public TO junior_analyst;
注意：GRANT 不会自动继承，必须显式授给视图；且 PostgreSQL 14+ 才支持 WITH CHECK OPTION 控制 INSERT/UPDATE，但对 SELECT 隐藏字段无影响。
MySQL 用户怎么办：没有列权限时的务实替代方案
MySQL 5.7/8.0 默认不支持列级权限（GRANT SELECT(id,name) ON db.t TO u 语法无效），所以只能靠间接手段：
- 建视图时用常量或空值代替敏感字段：例如
NULL AS salary或'HIDDEN'::TEXT AS salary_level - 把真实薪资表移出业务库，仅保留脱敏后聚合视图（如按部门平均薪资）
- 应用连接数据库时，固定使用一个低权限账号，该账号只被授予视图权限，且 DBA 禁用其
SHOW CREATE VIEW和SELECT对系统表的权限
最易被忽略的是：MySQL 的视图依赖于 SQL SECURITY DEFINER 设置。若设为 INVOKER，而调用者权限不足，查询直接报错；若设为 DEFINER，则需确保 definer 账号本身无越权风险——这个 definer 往往就是 DBA 自己的高权账号。
