相关子查询不能用于CHECK约束等强制拦截场景，因其违反确定性要求；跨表存在性校验应优先用EXISTS而非IN，且需确保关联字段有索引、子查询返回单值并显式处理NULL。
相关子查询不能直接用于数据合规性校验的强制拦截，比如 CHECK 约束、触发器中的 SIGNAL 条件或 INSERT/UPDATE 的前置断言——这不是写法问题，是数据库引擎的硬性限制。
WHERE 中用 EXISTS 做动态存在性校验
这是最常用也最安全的合规性验证场景：查“所有已通过实名认证且绑定有效银行卡的用户”。这类规则本质是跨表存在性判断，必须用 EXISTS 而非 IN。
-
EXISTS不受子查询字段为NULL影响；IN遇到NULL会整体返回UNKNOWN，导致行被静默丢弃 - 子查询里写
SELECT 1，避免解析多余列，部分数据库可跳过字段绑定开销 - 关联字段（如
bank_cards.user_id）必须有索引，否则主表每行都触发一次全表扫描 - 错误写法：
WHERE user_id IN (SELECT user_id FROM bank_cards WHERE status = 'active') - 正确写法：
WHERE EXISTS (SELECT 1 FROM bank_cards WHERE bank_cards.user_id = users.id AND status = 'active')
SELECT 列表中返回标量校验结果
当需要在查询结果中附带“是否合规”的标记字段（例如 is_compliant），相关子查询是直白的选择，但必须确保它只返回单值。
- 每个子查询结尾加
LIMIT 1或用聚合函数（如MAX(1)、COUNT(*)）强制单行，否则报错Subquery returns more than 1 row - 用
COALESCE((SELECT ...), 0)显式处理NULL，避免后续参与计算时因类型隐式转换出错 - 避免在
CASE WHEN里嵌套多层相关子查询：分支返回类型不一致（字符串 vs 数字）会导致排序错乱或比较失效 - 示例：
(SELECT COALESCE(MAX(1), 0) FROM idv_records i WHERE i.user_id = u.id AND i.status = 'verified') AS is_compliant
UPDATE/DELETE 中慎用相关子查询做条件驱动
看似方便的写法，比如“把所有未完成 KYC 的用户状态置为 pending”，实际极易引发性能崩塌和语义模糊。
- 优化器难推导执行计划，MySQL 对
UPDATE子查询还有额外限制（如禁止引用目标表别名） - 优先改用
JOIN：UPDATE users u JOIN kyc_status k ON u.id = k.user_id SET u.status = 'pending' WHERE k.status != 'completed' - 若必须用子查询，确保子查询只读、无聚合、有关联索引，并测试百万级数据下的执行时间
- 禁止在子查询中调用非确定性函数（如
NOW()、RAND()），否则结果不可复现
用 FROM 子句物化中间结果再比对
真正可靠的合规性校核不是靠 WHERE 里嵌套子查询“一锤定音”，而是分步暴露差异。比如验证“订单总金额是否等于明细 sum(amount)”。
- 错误做法：
WHERE o.total != (SELECT SUM(amount) FROM order_items i WHERE i.order_id = o.id)—— 每行重算一次，无索引则全表扫 - 正确做法：先在
FROM中物化明细汇总，再LEFT JOIN比对，显式输出差值 -
COALESCE(t.sum_amount, 0)必须显式处理无明细订单（NULL → 0），否则比较结果为UNKNOWN - GROUP BY 字段（如
order_id）必须有索引，否则子查询本身就会慢 - 结果集直接暴露
total_from_order和total_from_items，能快速定位是主表错、明细漏，还是精度/类型不一致
最容易被忽略的一点：相关子查询的执行时机依赖于主查询的每一行，这意味着它无法跨事务快照保证一致性。如果校核逻辑涉及“某时刻的状态”（比如订单创建时的风控等级），子查询里用 NOW() 或未加版本约束的 JOIN，结果可能在高并发下失真。这种场景必须提前固化快照，而不是靠运行时临时查。
