子查询脱敏必须用case when显式嵌入掩码逻辑，不可直接select原始字段；需结合行级安全与字段级脱敏分离设计，避免where中误用脱敏值过滤。
子查询脱敏必须用 CASE WHEN 而非直接 SELECT
直接在子查询里 SELECT name 不会自动脱敏，脱敏逻辑必须显式嵌入表达式。常见错误是写成 SELECT (SELECT name FROM users WHERE id = o.user_id) AS user_name——这暴露原始值。正确做法是把脱敏逻辑（如掩码、哈希、截断）塞进子查询的 CASE WHEN 或函数调用里。
典型场景：订单表 orders 关联用户姓名，但只对非管理员角色显示“张*”格式：
SELECT
order_id,
(SELECT CASE
WHEN current_role() = 'admin' THEN u.name
ELSE CONCAT(LEFT(u.name, 1), '*')
END
FROM users u
WHERE u.id = orders.user_id) AS user_name
FROM orders;
-
current_role()是数据库支持的角色判断函数（PostgreSQL 用current_user+ 权限表，MySQL 可用自定义函数） - 子查询必须返回单行单列，否则报错
Subquery returns more than 1 row - 避免在子查询里做复杂计算（如 SHA2），否则全表扫描时性能陡降
WHERE 条件中用子查询脱敏会彻底失效
脱敏是展示层行为，不是过滤逻辑。如果在 WHERE 里写 name LIKE (SELECT CONCAT('%', LEFT(real_name,1), '%') FROM ...)，本质是拿脱敏后的值去查原始数据，结果必然为空或错配。
真正需要的是「权限驱动的行级过滤」+「字段级脱敏」分离：
- 先用行级安全策略（如 PostgreSQL RLS 或 MySQL 5.7+ 的
WHERE视图）控制谁能查哪些行 - 再在 SELECT 列表里用子查询或
CASE控制每列怎么显示 - 不要试图用子查询在
WHERE中“反向推导”脱敏规则
MySQL 8.0+ 支持内联表值函数，比相关子查询更可控
相关子查询（correlated subquery）每行执行一次，大数据量下 I/O 压力大。MySQL 8.0+ 可用 LATERAL 或物化 CTE 预处理脱敏映射：
WITH masked_users AS (
SELECT
id,
CASE WHEN @role = 'admin' THEN name ELSE CONCAT(LEFT(name,1), '*') END AS masked_name
FROM users
)
SELECT o.order_id, mu.masked_name
FROM orders o
LATERAL (SELECT masked_name FROM masked_users mu2 WHERE mu2.id = o.user_id) mu;
-
@role需提前SET @role = 'user';，不能依赖运行时会话变量自动识别（不安全） -
LATERAL允许右侧引用左侧字段，语义比相关子查询清晰 - 若数据库不支持
LATERAL（如 MySQL 5.7），老老实实用带EXISTS的关联子查询，别硬套
JSON 字段里的敏感值无法靠 SQL 子查询动态脱敏
当姓名、手机号存在 JSON 列（如 extra_info JSON）里，(SELECT ...) 拿不到键值对内部结构。MySQL 的 JSON_EXTRACT 只能取值，不能条件性掩码。
可行路径只有两条：
- 拆出关键字段建冗余列（如
user_phone_plain），再按常规方式子查询脱敏 - 应用层解包 JSON，用业务代码做脱敏（如 Python 的
re.sub(r'(\d{3})\d{4}(\d{4})', r'\1****\2', phone)） - 数据库原生不支持 JSON 内部字段的条件掩码，别在子查询里写
JSON_EXTRACT(...)套CASE——语法报错或返回 NULL
脱敏真正的复杂点不在 SQL 写法，而在于角色判定如何与数据库会话绑定。靠 current_user 很容易被绕过，必须和应用层 token 解析联动，否则子查询里写的 IF 全是摆设。
