视图不能隐藏表的物理结构细节，它只提供一层查询封装；真正起作用的是权限隔离+显式字段控制+避免元数据泄露组合动作，因为show create view等元数据查询会明文暴露底层表名、字段及函数逻辑，必须同步撤销基表权限、限制schema访问并仅授予视图权限才能构成有效防护。
视图不能隐藏表的物理结构细节，它只提供一层查询封装；真正起作用的是权限隔离 + 显式字段控制 + 避免元数据泄露组合动作。
为什么 SHOW CREATE VIEW 一查就露馅
视图定义本身是明文存储的。任何有 SHOW CREATE VIEW 权限的用户（比如 DBA 或高权限应用账号）都能执行：
SHOW CREATE VIEW v_user_safe;
结果里直接包含 SELECT id, name, SUBSTRING(phone, 1, 3) AS phone_prefix FROM users 这类语句——底层表名、字段名、函数逻辑全在。所谓“隐藏”，只是让普通用户没权限看这个语句而已。
- MySQL 中默认不授予普通用户该权限，但若误授，防护即失效
- PostgreSQL 中查
pg_views.definition同样暴露全部依赖 - SQL Server 中用
sys.views+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 就报错，但已知结构存在。
字段别名和计算列会反向泄露结构信息
视图里把 id_card 写成 identity_masked 看似安全，但别名本身可能暗示原字段含义；更危险的是表达式残留：
-
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能看到列名和类型
最干净的做法是：敏感字段压根不出现。需要脱敏时，优先用应用层处理，或数据库侧用动态脱敏策略（如 SQL Server 的 RLS 或 MySQL 8.0+ 的 Data Masking 插件），而非在视图里硬编码逻辑。
嵌套视图会让结构暴露更难排查
当 v1 基于 v2，v2 又基于 users，用户查 v1 报错时，错误堆栈不会显示 users。但执行 EXPLAIN SELECT * FROM v1 WHERE id = 123，如果看到扫描对象是 v2 而不是具体表名，说明优化器已“藏”了一层——但这不是安全，是调试障碍。
- PostgreSQL 的
pg_depend仍能顺藤摸瓜查到v1 → v2 → users - MySQL 8.0+ 的
INFORMATION_SCHEMA.VIEWS里VIEW_DEFINITION字段存的是原始 SQL，嵌套层级越高，越容易因字符截断丢失关键信息 - 扁平化始终优于嵌套：把多层逻辑压进单个视图定义，既减少解析开销，也降低元数据泄露面
复杂点不在语法，而在权限边界是否真被切干净——哪怕视图定义写得再“抽象”，只要基表权限没砍断，物理结构就等于没隐藏。
