视图本身不隐藏物理结构，真正起作用的是权限控制、显式字段声明和元数据访问限制三者缺一不可；仅建视图无防护，SHOW CREATE VIEW会明文暴露底层表名、字段及函数逻辑，必须同步撤销基表权限、禁用schema浏览并仅授予视图查询权。
视图本身不隐藏物理结构，它只是把查询语句存下来；真正起作用的是权限控制 + 显式字段声明 + 元数据访问限制这三件事。光建一个 CREATE VIEW，等于什么防护都没做。
SHOW CREATE VIEW 一查就暴露全部细节
视图定义是明文存储的，任何有对应权限的用户都能直接看到底层表名、字段、函数甚至注释。比如执行：
SHOW CREATE VIEW v_user_safe;
结果里会清清楚楚写着：
SELECT id, name, SUBSTRING(phone, 1, 3) AS phone_prefix FROM users;
这意味着：
-
users表名、phone字段名、SUBSTRING函数逻辑全被泄露 - MySQL 默认不给普通用户该权限，但若误授（比如 DBA 批量授权），防护立即失效
- PostgreSQL 查
pg_views.definition、SQL Server 查sys.sql_modules同样能还原原始 SQL
必须同步执行的三步权限操作
只建视图不改权限，相当于锁了门却把钥匙挂在门把手上。有效防护依赖以下三步同时生效：
-
REVOKE SELECT ON TABLE users FROM 'app_user'@'%';—— 撤掉基表直查权限 -
REVOKE USAGE ON SCHEMA public FROM 'app_user'@'%';—— PostgreSQL 下防止\dt看到表名；MySQL 8.0+ 要确认没被间接赋予mysql.role_edges -
GRANT SELECT ON v_user_safe TO 'app_user'@'%';—— 只放行视图，且确保不能跨 schema 引用（如otherdb.users）
漏掉任意一步，用户都可能绕过：比如只撤了 SELECT 却留着 USAGE，在 psql 里敲 \dt 仍能看到 users 表名，再试 SELECT * FROM users LIMIT 1 就报错，但结构已知。
字段别名和表达式会反向泄露业务含义
视图里写 SUBSTRING(id_card, 1, 6) AS id_head，别名 id_head 加函数参数 6，基本可反推原字段含身份证号；COALESCE(salary, 0) AS base_pay 则暴露原字段允许 NULL、业务叫“底薪”。更危险的是：
- 用
CONCAT('***', RIGHT(ssn, 4))而不是直接省略字段 ——DESCRIBE v_user_safe仍能看到列名和类型 - 别名还叫
phone或email—— 前端或 ORM 可能直接拿去校验或更新，审计工具也识别不出这是掩码值 - 最干净做法：敏感字段压根不出现；脱敏优先放在应用层，或启用数据库原生动态脱敏（如 SQL Server RLS、MySQL 8.0+ Data Masking 插件）
真正难的不是写 CREATE VIEW，而是确保权限链完全切断、元数据不可见、字段无语义残留——这三个条件缺一不可，且任一环节出问题，物理结构就等于裸奔。
