SQL视图能隐藏敏感列，但不能替代真正的列级权限控制——它只是逻辑隔离，不是安全边界；必须配合收回基表权限、仅授予视图权限、禁用基表schema访问及设置视图只读，才能构成有效防护。
直接说结论：SQL视图能隐藏敏感列，但不能替代真正的列级权限控制——它只是逻辑隔离，不是安全边界。
视图确实能“不查敏感列”，但绕过它太容易
创建视图时跳过 ssn、salary、password_hash 等列，应用层查询视图就看不到这些字段。这很常见，也有效，但前提是用户只能访问视图，不能直连基表。
- 如果用户有基表的
SELECT权限，ta 可以直接SELECT ssn FROM users，视图完全无效 - 如果用户能执行
pg_catalog查询（如 PostgreSQL）或INFORMATION_SCHEMA.COLUMNS，就能发现基表结构和被隐藏的列 - 视图定义本身可被读取（如
pg_views或sys.views），敏感列名可能暴露在注释或列别名里
真正起作用的是权限回收 + 视图授权组合
视图只有配合严格的权限管理才构成最小可行防护。关键动作不是“建视图”，而是“砍权限”。
- 先
REVOKE SELECT ON users FROM app_user（收回基表权限） - 再
GRANT SELECT ON user_public_view TO app_user（只授视图权限） - 确保该用户没有
USAGE权限到基表所在 schema，否则可能通过schema_name.table_name显式引用绕过 - PostgreSQL 中需额外
REVOKE USAGE ON SCHEMA public FROM app_user；MySQL 8.0+ 需确认mysql.role_edges未间接赋予基表权限
注意视图的“可更新性”会破坏列屏蔽效果
如果视图是可更新的（比如没含聚合、没去重、单表且无表达式），用户可能通过 INSERT 或 UPDATE 间接写入被隐藏列——尤其当视图定义中用了 COALESCE(salary, 0) 这类表达式时，某些数据库允许反向推导并修改源列。
- MySQL 默认视图不可更新，但加了
WITH CHECK OPTION后仍可能因条件宽松导致越权写入 - PostgreSQL 中用
CREATE VIEW ... WITH LOCAL CHECK OPTION只校验当前视图层，不阻止对基表的直接操作 - 最稳妥做法：对敏感列所在的视图，显式声明为只读——SQL Server 用
SCHEMABINDING+ 不含计算列；PostgreSQL 用CREATE VIEW ... AS SELECT ...不带INSTEAD OFtrigger
别依赖视图做加密或脱敏逻辑
有人在视图里写 CONCAT('***', SUBSTRING(ssn, -4))，以为就算“处理”了敏感数据。问题在于：
- 这种脱敏发生在查询时，意味着数据库仍以明文存储和传输完整
ssn，网络抓包或内存 dump 仍可能泄露 - 若应用层缓存了视图结果，脱敏值可能被误当作原始数据使用（比如下游系统拿
***1234做唯一键） - 列类型可能暴露信息：
CHAR(11)的脱敏列 vsVARCHAR(20)的真实列，结合业务上下文易被反推
真要脱敏，应在应用层或使用数据库原生动态数据掩码（如 SQL Server 的 ADD MASKED，Oracle 的 DBMS_REDACT），而不是靠视图“假装看不见”。
