NOT EXISTS 比 LEFT JOIN 更可靠地查询A表存在而B表无匹配的数据，尤其当B表关联字段允许NULL时；需确保子查询含相关条件、关联字段类型一致且有索引，子查询应写SELECT 1，避免函数导致索引失效。
子查询 WHERE NOT EXISTS 比 LEFT JOIN 更稳
查“在 A 表里存在、但在 B 表里没匹配到”的无效数据时，
通常比
更可靠。尤其当 B 表关联字段允许
时，
容易漏判或误判——因为
条件里含
会导致整行被过滤掉，而
只关心子查询是否返回结果，逻辑更干净。
实操建议：
用
替代
：后者遇到子查询结果含
会整个返回空集，是经典陷阱
子查询里必须加相关条件（比如
），否则变成全表扫描，性能断崖下跌
确保子查询中关联字段有索引，否则
也会慢得像全表嵌套循环
示例：
关联字段类型不一致导致子查询静默失效
看似能跑通的子查询，结果却总是空，大概率是主表和子查询里用于关联的字段类型不一致——比如一边是
，另一边是
，数据库会隐式转换，但可能触发索引失效或比较逻辑异常（如字符串前导零、空格截断）。
实操建议：
用
或
对比两边字段类型，别只看名字
显式转换比依赖隐式转换安全：
（MySQL）或
（PostgreSQL）
如果字段是带前导零的编码（如
），别用数字类型存，统一用字符串并加索引
子查询返回多列引发语法错误
和
只关心子查询是否返回行，不关心返回什么内容，但很多人写成
或多列，虽然多数数据库允许，但一旦子查询里用了聚合或窗口函数，就容易报错，比如
。
实操建议：
子查询里永远用
或
，语义清晰且兼容所有主流数据库
避免在
子查询里写
、
、
（除非必要），这些不是标准 SQL 支持的，MySQL 允许但 PostgreSQL 会直接报错
如果真要校验“是否存在多个匹配”，应改用
的独立子查询，而不是塞进
大数据量下子查询性能突然变差
小表测试时飞快，一上生产环境就超时，往往是因为子查询没走索引，或者优化器选错了执行计划——特别是当子查询里用了函数（如
、
）或表达式时，索引直接失效。
实操建议：
用
看子查询是否命中索引，重点看
是不是
或
，如果是
或
就危险了
关联字段上有函数？那就建函数索引（MySQL 8.0+、PostgreSQL 支持）：
子查询太重？考虑提前物化：先
存下校验集合，再用
查，有时比反复执行子查询快十倍
真正难的不是写出子查询，而是确认它在各种数据分布、类型组合、索引状态下的行为都符合预期。尤其是跨库迁移或升级数据库版本后，隐式转换规则和优化器策略可能已变，老 SQL 很容易悄悄出错。
NOT EXISTSLEFT JOIN ... IS NULLNULLLEFT JOINONNULLNOT EXISTSNOT EXISTSNOT INNULLWHERE b.id = a.ref_idNOT EXISTSSELECT * FROM orders a
WHERE NOT EXISTS (
SELECT 1 FROM customers b
WHERE b.id = a.customer_id
);INTVARCHARDESCRIBE table_nameSHOW COLUMNSWHERE b.id = CAST(a.ref_id AS SIGNED)WHERE b.id::text = a.ref_id'00123'EXISTSNOT EXISTSSELECT *ERROR: subquery must return only one columnSELECT 1SELECT NULLEXISTSGROUP BYORDER BYLIMITCOUNT(*) > 1EXISTSUPPER()TRIM()EXPLAINtyperefeq_refALLindexCREATE INDEX idx_customer_upper ON customers (UPPER(email))CREATE TEMP TABLENOT EXISTS