NOT EXISTS 比 NOT IN 更安全，因 NOT IN 遇 NULL 返回空结果致漏查，而 NOT EXISTS 不受 NULL 干扰且语义清晰；多层嵌套子查询易性能雪崩，应物化中间结果、确保索引命中；CHECK 约束不支持子查询，需外键 + 触发器 + 应用校验协同保障数据完整性。
子查询里用 NOT EXISTS 比 NOT IN 更安全
遇到主表某字段必须在从表中存在（或必须不存在）的校验，直接写 NOT IN 很容易掉坑里——只要从表的关联字段有 NULL，整条 NOT IN 判断就返回空结果，导致漏查。这不是 bug，是 SQL 三值逻辑的必然行为。
实操建议：
- 检查“订单表中客户 ID 是否都在客户表里”，用
NOT EXISTS替代NOT IN -
NOT EXISTS不受NULL干扰，语义清晰：只要找不到匹配行，就为真 - 注意子查询里要加相关条件（比如
WHERE c.id = o.customer_id），否则变成全表扫描
SELECT * FROM orders o WHERE NOT EXISTS (SELECT 1 FROM customers c WHERE c.id = o.customer_id);多层嵌套子查询容易触发性能雪崩
当子查询里再套子查询（比如三层以上），尤其每层都涉及大表或没走索引，执行计划很容易退化成嵌套循环 + 全表扫描，响应时间从毫秒级跳到秒级甚至超时。
实操建议：
- 优先把中间结果物化：用
WITH临时表提前算好关键字段，避免重复计算 - 确认每层子查询的
WHERE条件是否能命中索引；特别留意IN (子查询）中的子查询是否返回过多行 - PostgreSQL 和 MySQL 8.0+ 支持
LATERAL，适合需要依赖外层字段做动态关联的场景，比多层嵌套更可控
CHECK 约束不支持子查询，别硬塞
想在建表时用 CHECK (status IN (SELECT code FROM status_ref))？所有主流数据库都会报错：CHECK 约束只允许确定性表达式，不能引用其他表。
实操建议：
- 数据完整性得靠应用层校验 + 外键约束 + 触发器三者配合，不能只押注
CHECK - 如果必须动态检查（比如状态值随配置表变化），用触发器比在应用里写逻辑更可靠，但要注意触发器里的子查询同样要防
NULL和性能问题 - MySQL 8.0.16+ 支持函数索引，可把子查询逻辑封装进函数再建索引，但仅限简单场景，慎用
子查询返回多行时，= 和 IN 的行为差异很关键
写 WHERE amount = (SELECT max_amount FROM limits) 却忘了子查询可能返回多行？直接报错 Subquery returns more than 1 row。而 IN 虽然不报错，但语义已变——它变成“是否属于这个集合”，不是“是否等于某个唯一值”。
实操建议：
- 明确子查询预期结果行数：单值就用
=或>等标量比较符，并加LIMIT 1防错（但要清楚丢数据风险） - 不确定行数或本来就要匹配集合，统一用
IN，但记得子查询里过滤掉NULL（WHERE col IS NOT NULL） - 用
ANY/ALL可以更精准表达“大于其中任一”或“小于全部”，但可读性差，调试困难
复杂点往往不在语法对不对，而在子查询的执行时机、NULL 处理和索引覆盖是否被你真正看见。
