视图中用CASE WHEN对敏感字段脱敏最常用且可控，需配合LENGTH或正则校验格式，确保空值和异常数据不漏脱敏；必须严格控制基表权限，仅授予视图权限才能保障脱敏有效。
视图里用 CASE WHEN 替换手机号、身份证号
直接在 SELECT 里对敏感字段做条件替换，是最常用也最可控的方式。比如把手机号后4位打码，身份证号只留前6位和后4位，其他字符用星号代替。
关键不是“能不能藏”，而是“藏得是否一致且不可逆”——视图本身不存数据，每次查都实时计算，所以只要逻辑写对，脱敏结果就稳定。
-
CASE WHEN必须配合LENGTH或正则判断字段是否非空/格式合法，否则空值或异常格式会漏脱敏，甚至报错 - MySQL 8.0+ 可用
REGEXP_SUBSTR提取身份证号段，但低版本只能靠SUBSTRING+LENGTH组合，要先TRIM再判断长度，否则带空格的身份证号会截错 - PostgreSQL 要注意
NULL和空字符串的区别：''不触发WHEN phone IS NOT NULL，得单独写WHEN phone != ''
示例（MySQL）：
SELECT id, name,
CASE
WHEN phone REGEXP '^1[3-9]\d{9}$'
THEN CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))
ELSE '****'
END AS phone,
CASE
WHEN id_card REGEXP '^\d{17}[\dXx]$'
THEN CONCAT(LEFT(id_card, 6), '******', RIGHT(id_card, 4))
ELSE '********'
END AS id_card
FROM users;
用视图权限控制谁能看到原始字段
脱敏不是靠“看不见”，而是靠“没权限看”。即使视图里写了原始字段，只要不给用户查基表的权限，他们就只能看到视图定义的内容。
很多人以为建了视图就自动脱敏了，其实如果还给了 SELECT 基表的权限，用户绕开视图直接查原表，脱敏就完全失效。
- 建完视图后，必须显式执行
REVOKE SELECT ON users FROM 'user_a'@'%'，再GRANT SELECT ON user_view TO 'user_a'@'%' - MySQL 8.0+ 支持角色（
ROLE），建议把脱敏视图权限打包成角色，避免漏授或误授 - Oracle 中视图列名若和基表一样，且用户有基表
SELECT权限，EXPLAIN PLAN可能暴露原始访问路径，需额外检查执行计划
JSON 字段里的敏感信息怎么脱敏
当用户信息存在 meta 这种 JSON 字段里时，不能只脱敏外层字段——视图无法自动递归解析 JSON，必须显式提取再处理。
不同数据库对 JSON 的支持差异很大，硬套一个写法容易在迁移或升级后崩掉。
- MySQL 5.7+ 用
JSON_EXTRACT(meta, '$.phone')提取，但返回带引号字符串，得套一层TRIM(BOTH '"' FROM ...)才能进CASE WHEN - PostgreSQL 用
meta->>'phone'，但若字段不存在会返回NULL，而 MySQL 的JSON_EXTRACT返回NULL或NULL字符串，行为不一致 - SQL Server 2016+ 要用
JSON_VALUE(meta, '$.phone')，且必须确保meta是有效 JSON，否则整行查询失败，建议外层加ISJSON(meta) = 1过滤
示例（PostgreSQL）：
SELECT id, name,
CASE
WHEN meta ? 'phone' AND (meta->>'phone') ~ '^1[3-9]d{9}$'
THEN LEFT(meta->>'phone', 3) || '****' || RIGHT(meta->>'phone', 4)
ELSE '****'
END AS phone
FROM users;
WHERE 条件里还能用脱敏后的字段吗
不能。视图输出的脱敏字段是表达式结果，不是真实列，大多数数据库不支持在 WHERE 中直接对它做等值或模糊匹配——优化器没法下推，要么报错，要么全表扫描。
想按手机号搜索？得在视图里保留一个可索引的原始字段别名（如 phone_raw），再用权限控制不让用户 SELECT 它，只允许在 WHERE 里用。
- MySQL 视图中若包含表达式列（如
CASE WHEN...），该列默认不可用于WHERE下推，即便看起来是确定性函数 - PostgreSQL 的物化视图可以索引表达式列，但普通视图不行；真要高频检索，不如建生成列（
GENERATED ALWAYS AS (...) STORED）+ 索引 - 如果业务坚持“连 raw 字段都不能露”，那只能把检索逻辑下沉到应用层：先用脱敏视图查 ID 列表，再用 ID 去基表查原始值——但这就绕过了视图脱敏的意义
脱敏视图真正难的不是写 SQL，而是确认“哪些人、在什么上下文、通过什么方式”会接触到哪一层数据。一个字段在视图里打了码，不代表它在慢查询日志、备份文件、ETL 中间表、甚至数据库连接池的预编译缓存里也被处理了。这些地方，视图管不到。
