子查询必须返回单行单列，否则报错；脱敏逻辑须嵌套在子查询select中，不可外包或用于where条件；应优先用cte/lateral替代相关子查询以提升性能。
子查询必须返回单行单列，否则直接报错
相关子查询在脱敏场景中常被误用为“查用户再掩码”，但数据库对子查询结果有严格限制：它只能返回一个值。一旦 WHERE u.id = orders.user_id 匹配到多条或零条记录，就会抛出 Subquery returns more than 1 row 或空值导致整列变 NULL。
实操建议：
- 子查询内部必须加唯一性约束，例如
WHERE u.id = o.user_id AND u.status = 'active' - 外层
SELECT中避免对可能为空的子查询做字符串拼接（如CONCAT(LEFT((SELECT ...), 1), '*')），否则整字段静默失效 - MySQL 8.0+ 可用
LIMIT 1强制截断，但属兜底手段，不解决数据逻辑问题
CASE WHEN 必须写在子查询内部，不能外包
常见错误是把角色判断放在外层，比如 SELECT (SELECT u.name FROM users u WHERE u.id = o.user_id) AS user_name FROM orders o WHERE current_role() != 'admin'——这根本没脱敏，只是过滤了行。
真正生效的脱敏逻辑必须嵌套在子查询的 SELECT 列表里：
- 正确写法：
(SELECT CASE WHEN current_role() = 'admin' THEN u.name ELSE CONCAT(LEFT(u.name, 1), '*') END FROM users u WHERE u.id = o.user_id) - PostgreSQL 用户需配合 RLS 或自定义函数模拟
current_role()，不能依赖CURRENT_USER直接比对角色名 - MySQL 没有原生角色函数，得用
SELECT USER()+ 权限表 JOIN，或提前SET @role = 'user'（注意会话变量不可跨连接复用）
WHERE 中绝不能用脱敏值做条件匹配
脱敏是展示行为，不是筛选依据。如果写成 WHERE name LIKE (SELECT CONCAT('%', LEFT(real_name, 1), '%') FROM ...)，等于拿“张*”去查原始“张三丰”，结果必然为空或误命中。
这类写法还会触发全表扫描——因为子查询结果不可索引，优化器放弃使用 name 字段上的索引。
该规避的典型场景：
- 用
MD5(phone)在WHERE里比对，性能崩盘且语义错误 - 把
SUBSTRING(id_card, 1, 6)当作业务主键参与关联，忽略身份证升位、空格等脏数据 - 在子查询中调用非确定性函数（如
NOW()、RAND()），导致视图无法物化或执行计划抖动
大数据量下优先用 LATERAL 或 CTE 预计算映射
相关子查询每处理订单表一行，就重新查一次用户表，I/O 压力随订单量线性增长。10 万订单 ≈ 10 万次单行查询，远不如一次 JOIN 高效。
MySQL 8.0+ 和 PostgreSQL 12+ 支持更可控的替代方案：
- 用
WITH masked_users AS (...)先生成脱敏映射快照，再通过LATERAL或JOIN关联，把 N 次查询压成 1 次 -
LATERAL允许右侧子句引用左侧字段（如o.user_id），语义比相关子查询清晰，也更容易被优化器下推过滤条件 - CTE 中的脱敏逻辑可复用，比如同一张
masked_users同时供给user_name和user_phone两列，避免重复计算
TRIM() 漏掉，LEFT(NULL, 3) 返回 NULL，整个脱敏字段就塌了；身份证字段若含 X 尾缀却没统一转大写，SUBSTRING 算错位置，掩码就错位。这些不会报错，只会悄悄返回错误结果。
