CASE WHEN 是唯一可靠且跨数据库兼容的动态脱敏手段，因其在 MySQL/PostgreSQL/SQL Server 中均原生支持，而 MASKED WITH、MASK() 等语法或不存在或受限于表定义；必须显式校验 NULL 和格式，如 phone REGEXP '^1[3-9]d{9}$'，并设置 ELSE '***' 分支；视图脱敏生效前提为严格回收基表权限（如 REVOKE SELECT ON users），否则无效；WHERE 条件不可依赖脱敏计算字段，须基于原始字段过滤。
CASE WHEN 是唯一可靠且跨数据库兼容的动态脱敏手段，其他所谓“函数调用”“MASKING语法”在 MySQL/PostgreSQL 中根本不存在或不起作用。
为什么不能用 MASKED WITH 或 MASK() 函数
SQL Server 的 MASKED WITH 只能在 CREATE TABLE 或 ALTER TABLE 的列定义中使用，不能出现在视图里；MySQL 8.0+ 根本没有 MASK() 函数——你执行 SELECT MASK(phone) 一定会报错 FUNCTION MASK does not exist；PostgreSQL 同样不提供原生列级掩码函数。所谓“云平台脱敏按钮”，背后是代理层重写 SQL，不是数据库能力。
CASE WHEN 脱敏必须显式处理 NULL 和格式校验
直接拼接字符串会把 NULL 字段变成空值，导致脱敏结果不可控。同时，若字段含非法格式（如手机号只有 7 位），RIGHT(phone, 4) 会静默返回空串，造成数据错位。
- 必须写
WHEN phone IS NOT NULL AND phone REGEXP '^1[3-9]\d{9}$'做前置校验 -
ELSE '***'分支不能省，否则NULL进来还是NULL - 避免用
REPLACE(phone, SUBSTR(phone,4,7), '****')：MySQL 某些版本对空子串行为不一致，易出错
示例（MySQL）：
SELECT
id,
name,
CASE
WHEN phone IS NOT NULL AND phone REGEXP '^1[3-9]\d{9}$'
THEN CONCAT(LEFT(phone,3), '****', RIGHT(phone,4))
ELSE '***'
END AS phone_masked
FROM users;
视图权限链断裂才是脱敏生效的前提
只建视图不回收基表权限，等于没做任何事。用户仍可 SELECT ssn FROM users 直取明文。
- 先执行
REVOKE SELECT ON users FROM 'app_user'@'%' - 再执行
GRANT SELECT ON user_safe TO 'app_user'@'%' - PostgreSQL 还需
REVOKE USAGE ON SCHEMA public FROM app_user，否则可通过public.users显式绕过 - 验证是否生效：
SHOW GRANTS FOR 'app_user'@'%'输出里不能出现ON mydb.users
WHERE 条件里永远别依赖脱敏字段
这是最隐蔽的翻车点。视图里的 phone_masked 是计算列，WHERE phone_masked = '138****1234' 永远查不到数据——因为 WHERE 阶段尚未执行 SELECT 表达式。
- 过滤必须回到原始字段：
WHERE phone LIKE '138%1234' - 如需高频按脱敏格式查询，应在基表加冗余字段（如
phone_prefix CHAR(3)）并建索引 - BI 工具常自动把筛选拖到视图字段上，得提前禁用该字段的过滤能力
REVOKE SELECT ON users ——只要这条命令没跑，所有花哨的脱敏逻辑都只是纸糊的墙。 
