在数据库设计里，表结构的隐私保护和上层业务的访问需求经常打架。比如一张用户表，既有昵称、头像这些可以公开的字段，也有手机号、身份证号这类敏感信息。如果直接把物理表开放给各个业务方查询，敏感数据就等于裸奔。SQL中的视图（VIEW）正是解决这类问题的关键工具，它可以在逻辑层面重新组织数据，只暴露该暴露的列。这篇文章就围绕视图隐藏列的实现方式和背后的逻辑分离思想，展开聊一聊具体怎么做以及为什么这么做。
视图隐藏列的基本原理与最简单做法
视图本质上是一条被命名并存储的SELECT语句，数据库在执行查询时会把它展开成子查询再处理。因为视图的定义完全由SELECT列表决定，所以最直接的隐藏列方式就是：在SELECT里只列出需要暴露的字段，不列的字段自然对外不可见。这就是所谓的选择列隐藏，也是绝大多数场景下的首选方案。
假设有一张用户基础表，包含敏感字段，我们可以这样建视图：
-- 物理表：包含敏感列
CREATE TABLE t_user (
id BIGINT PRIMARY KEY,
nickname VARCHAR(64),
avatar VARCHAR(255),
phone VARCHAR(20),
id_card VARCHAR(18),
created_at DATETIME
);
-- 视图：只暴露安全列，phone 和 id_card 被隐藏
CREATE VIEW v_user_public AS
SELECT id, nickname, avatar, created_at
FROM t_user;
建好视图后，普通业务方只要只被授予v_user_public的查询权限，而不授予t_user本身的权限，那么无论它怎么写查询，都无法接触到被隐藏的列。注意一个细节：视图隐藏列并不是把列删除或置空，而是让这条访问路径上根本不存在这些列的元数据，上层查询如果显式写了SELECT phone FROM v_user_public，数据库会直接报错提示列不存在。
这种方式的优势在于简单、零成本、语义清晰。但它也有局限：隐藏是全有或全无的，如果希望某些角色能看到手机号而另一些角色不能，就需要建多个视图配合权限体系，管理成本会随角色数量增长。这就引出了后面更灵活的做法。
列存在但不能看：脱敏与转换的进阶方案
有些业务场景下，列本身不能从结构里消失。比如报表需要统计手机号的归属地，或者风控需要判断身份证是否有效。这时候可以换一种思路：列在视图里保留，但对值做转换处理，也就是常说的数据脱敏。视图定义中利用字符串函数、CASE表达式等手段，把敏感值加工成可用但不泄露原值的形态。
下面是一个对手机号和身份证做部分遮蔽的视图示例：
CREATE VIEW v_user_masked AS
SELECT
id,
nickname,
-- 保留前三位和后四位，中间打码：138****5678
CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) AS phone_masked,
-- 身份证保留前六位和最后一位
CONCAT(LEFT(id_card, 6), '********', RIGHT(id_card, 1)) AS id_card_masked,
created_at
FROM t_user;
这种方案的好处是列的语义还在，上层系统可以照常引用phone_masked做展示，只是拿不到完整值。对于需要格式校验的场景，还可以进一步用函数生成哈希值，比如用MD5或SHA系列函数生成不可逆摘要，既满足等值匹配又不暴露原文：
CREATE VIEW v_user_hash AS
SELECT
id,
nickname,
SHA2(id_card, 256) AS id_card_hash
FROM t_user;
-- 上层按摘要匹配，不接触原文
SELECT id FROM v_user_hash WHERE id_card_hash = SHA2('110101199001011234', 256);
需要注意的是，不同数据库的函数名和参数有差异，MySQL用SHA2，PostgreSQL用DIGEST配合扩展，SQL Server则常用HASHBYTES。迁移方案时一定要核对具体语法。此外脱敏视图有一个隐患：如果有人能查询原始表或拿到库的超级权限，脱敏就形同虚设，所以它必须和权限管理配合使用，不能单独依赖。
用权限体系把隐藏落到实处
视图本身的隐藏能力，最终要靠数据库权限来兑现。只建视图不收权限，等于门装了锁却不上栓。标准做法是：收回物理表的所有授权，只针对视图授权查询。以MySQL为例，典型流程如下：
-- 创建业务账号 CREATE USER 'app_read'@'%' IDENTIFIED BY 'StrongPass!23'; -- 只授予视图的查询权限，不授予 t_user GRANT SELECT ON mydb.v_user_public TO 'app_read'@'%'; -- 回收可能存在的表级权限（保险起见） REVOKE ALL PRIVILEGES ON mydb.t_user FROM 'app_read'@'%'; FLUSH PRIVILEGES;
这样app_read账号在视图里看不到隐藏列，也绕不过去查物理表。这里有一个容易踩的坑：视图定义者权限问题。MySQL中默认使用DEFINER模式，如果视图的DEFINER是高权限账号，而业务账号拥有对视图的EXECUTE权限，某些配置下可能存在权限放大风险。建议给视图单独指定一个只具备最小权限的DEFINER账号，或者使用SQL SECURITY INVOKER让视图以调用者权限执行。
另一个配合手段是PostgreSQL的列级权限和行级安全策略。它允许直接对物理表的某一列单独授权，相当于把隐藏列的能力下沉到表层面：
-- PostgreSQL：只授予部分列的查询权限
GRANT SELECT (id, nickname, avatar, created_at) ON t_user TO app_read;
-- 行级安全：配合策略限制可见行
ALTER TABLE t_user ENABLE ROW LEVEL SECURITY;
CREATE POLICY p_dept_isolate ON t_user
USING (dept_id = current_setting('app.dept_id')::int);
列级权限和视图各有侧重：前者粒度更细、无需额外对象，后者胜在灵活，可以在同一份数据上叠加计算、遮蔽、过滤等多种逻辑。实际项目中两者常常组合使用，视图负责逻辑重塑，权限负责边界兜底。
逻辑分离的设计思想：为什么要这样拆
把视图隐藏列的做法往深里看，其实是逻辑分离设计思想的具体体现。核心观点是：物理表结构面向存储和一致性设计，对外接口面向消费方需求设计，两者不应该捆绑在一起。物理表怎么建、加什么列、怎么分区，是数据库内部的事；外部看到什么样的数据形态，由视图这一逻辑层来定义。中间隔了一层，两边就都可以独立演进。
这种分离带来的收益至少有三个。第一是接口稳定性。业务表加字段是常态，如果上层应用直接查物理表，任何结构变更都可能引发大面积报错；而通过视图暴露数据，物理表加列只要同步更新视图定义，上层查询完全无感。第二是敏感数据收敛。所有对外出口都收口到视图，审计时只需要检查视图定义是否符合脱敏规范，而不必逐个排查散落各处的SQL。第三是多场景复用。同一张物理表可以派生出面向App的精简视图、面向报表的宽表视图、面向第三方的脱敏视图，各自独立维护互不干扰。
当然，逻辑分离也不是没有代价。视图层数量一多，命名和文档管理要跟上，否则容易出现同一个字段在不同视图里口径不一致的问题。嵌套视图（视图套视图）超过两层还会显著增加排查难度，数据库优化器有时也难以穿过多层定义生成好的执行计划。比较务实的实践是：视图保持扁平，一层封装到位；敏感列的遮蔽规则统一定义，最好沉淀成可复用的函数；同时约定视图命名规范，比如v_业务域_场景的格式，让团队能一眼看出视图的用途和暴露范围。
总结一下，视图隐藏列从技术上讲只是SELECT列表的选择问题，但从设计上讲，它承载的是数据访问边界与存储结构解耦的思路。选列隐藏、脱敏转换、权限兜底，三种手段按需组合，再加上清晰的逻辑分层，基本能覆盖绝大多数数据安全与接口管理的需求。在动手建表之前先想清楚哪些列属于内部、哪些属于对外，往往比事后补救要省力得多。