sql server的masked with仅支持在create/alter table列定义中使用，不能在视图中调用；视图无法实现动态脱敏，仅可配合权限控制限制用户访问基表，真正脱敏必须依赖原生ddm机制。

SQL Server 的 MASKING 函数只能在列级动态数据脱敏（DDM）中使用，不能在视图里直接调用

这是最关键的误区：很多人想在 CREATE VIEW 里写 CONCAT('***', RIGHT(phone, 4)) 或调用 MASKED WITH，但后者根本不是函数，而是表定义语法；前者虽能运行，却绕过了权限控制机制，起不到真正的“动态”脱敏作用。

真正受控的脱敏必须基于数据库原生 DDM 功能，它只在 CREATE TABLE 或 ALTER TABLE 中对列声明生效，查询时由引擎自动拦截非授权用户的数据流。

• MASKED WITH (FUNCTION = 'default()')、'email()'、'partial(1,"XXXXXX",2)' 等仅支持在列定义中使用
• 视图中无法引用这些掩码逻辑——即使你 SELECT 该列，未授权用户看到的仍是脱敏后值，但视图本身不参与掩码决策
• 如果你在视图里手动拼接字符串做“假脱敏”，DBA 或高权限用户查基表仍能看到明文，且应用层无法区分谁该看什么

如何让视图配合 DDM 正常工作：授权与角色是关键

视图本身不改变脱敏行为，但它可以成为权限隔离的载体。DDM 生效的前提是用户没有 UNMASK 权限，而视图可用来限制用户只能访问特定列或行。

• 给普通用户只授予 SELECT 权限在视图上，而不是基表——避免他们绕过视图直接查原始列
• 确保该用户没有被显式授予 UNMASK 权限（哪怕只针对某张表），否则 DDM 彻底失效
• 可在视图中用 CASE WHEN IS_MEMBER('role_sensitive') = 1 THEN real_name ELSE '***' END 做补充判断，但这属于应用逻辑，不替代 DDM
• 注意：视图列若基于已启用 DDM 的基表列（如 SELECT id, email FROM users），则 email 列对无权限用户自动显示为 xxxx@xxxx.com（取决于掩码策略）

PostgreSQL / MySQL 用户别踩坑：它们压根没有内置 MASKING 函数

SQL Server 的 MASKED WITH 是特有功能，PostgreSQL 和 MySQL 不提供等价的列级动态脱敏机制。所谓 “使用 MASKING 函数” 在这两个系统里纯属误传。

• PostgreSQL 可通过 RLS（Row Level Security） + 自定义函数模拟部分效果，但需手动在每个查询中包裹逻辑，且无法做到“对同一列，不同用户看到不同脱敏形式”
• MySQL 8.0+ 支持 CREATE FUNCTION 返回脱敏值，但该函数会被所有用户执行，无法按角色切换策略；也不能阻止用户直接查原始字段
• 若强行在视图中写 REPLACE(ssn, SUBSTR(ssn, 2, 7), 'XXXXXXX')，结果是静态脱敏——开发、测试、生产环境全一样，且 DBA 查基表即破防
• 真正可行路径：用代理层（如 ProxySQL）、应用中间件或列加密（AES_ENCRYPT）替代，而非依赖不存在的 MASKING

为什么不要在视图里硬编码脱敏逻辑

手动脱敏视图看似灵活，实则破坏了审计一致性、权限边界和维护性。

• 同一个字段在多个视图中可能被不同方式处理（有的留前两位，有的留后四位），下游报表容易混乱
• 当合规要求升级（比如从掩码 4 位变成 6 位），要批量改 N 个视图，还可能漏掉某些 JOIN 场景
• 无法与企业级工具（如 Microsoft Purview、IBM Guardium）集成，它们依赖的是元数据中标记的 DDM 属性，而非 SQL 字符串
• 最隐蔽的问题：这类视图一旦被用于物化（如 PostgreSQL 的 MATERIALIZED VIEW），脱敏结果就固化成物理数据，彻底失去“动态”意义

DDM 的核心在于“权限驱动的实时重写”，不是字符串替换。视图只是出口，不是引擎。真正要花精力的地方，是基表列定义、角色划分、UNMASK 权限审计，以及确认你的备份/导出流程不会意外暴露掩码前的数据。