not exists必须用相关子查询，关联字段需为右表索引前缀；它比not in更安全，因不参与null比较；left join+is null易错，过滤条件须写在on中。
NOT EXISTS 必须写成相关子查询，否则逻辑全错
子查询里漏掉对外部表的引用，就变成固定真假值——比如 WHERE NOT EXISTS (SELECT 1 FROM orders WHERE status = 'shipped')，这和主表 users 完全无关，结果恒为真或假，查出来的不是“没下单的用户”，而是要么全表、要么空集。
正确写法必须含明确关联：子查询的 WHERE 条件里至少有一个等值引用，如 o.user_id = u.id。这个关联是语义成立的前提，也是优化器识别反连接的唯一线索。
- 别用
SELECT *或SELECT COUNT(*)——SELECT 1最轻量，优化器不关心返回什么，只看是否返回行 - 子查询里不要加
GROUP BY、ORDER BY或聚合函数，它们无意义且可能阻止优化器下推 - 如果右表有多个匹配字段（如需同时比对
ipaddr和name），直接写WHERE o.ipaddr = u.ipaddr AND o.name = u.name，天然支持，不用元组
为什么 NOT EXISTS 比 NOT IN 更安全？NULL 是隐形杀手
NOT IN 遇到右表字段含 NULL 时直接失效：只要子查询返回任意一个 NULL（比如 orders.user_id 允许为空），整个条件判定为 UNKNOWN，结果集为空——你查不到任何用户，哪怕他们确实没下单。
NOT EXISTS 完全绕过 NULL 参与比较：它只问“有没有行满足条件”，不关心字段值是不是 NULL。哪怕 orders 表里 user_id 大量为 NULL，只要没匹配上当前 u.id，就认为“不存在”，逻辑稳定。
- 约束可能被临时禁用（如批量导入时），
NOT IN在此期间静默失败；NOT EXISTS不依赖约束，更鲁棒 - 业务字段允许
NULL是常态，别指望靠加WHERE user_id IS NOT NULL修复NOT IN—— 子查询里加了，外层NOT IN还是会因其他地方的NULL崩溃
索引怎么配？子查询 WHERE 条件必须命中索引前缀
写了 NOT EXISTS 不等于自动高效。性能取决于子查询能否走索引探查（Index Seek / Index Only Scan），而不是全表扫描。
关键原则：子查询 WHERE 中用于关联的字段（如 o.user_id），必须是右表索引的最左前缀。例如右表 orders(user_id, status) 有复合索引，WHERE o.user_id = u.id AND o.status = 'active' 能用；但 WHERE o.status = 'active' AND o.user_id = u.id 就可能失效（取决于优化器和版本）。
- 避免在关联字段上用函数：
WHERE YEAR(o.created_at) = 2025或UPPER(o.email) = 'A@B.COM'会让索引完全失效 - 如果右表关联字段允许
NULL，但业务上“有效匹配”本就不含NULL，可在子查询中显式加AND o.user_id IS NOT NULL，帮优化器更准确认知选择率 - 字段类型必须严格一致：
users.id是BIGINT，orders.user_id也得是BIGINT，隐式转换会丢索引
LEFT JOIN + IS NULL 看似简单，其实更容易踩坑
它调试直观，但两个细节一错就全错：判空字段必须是右表的**关联外键**（如 o.user_id），不能是右表主键（如 o.id）；右表的业务过滤条件（如时间范围、状态）必须写在 ON 子句，不能放 WHERE。
错误示例：WHERE o.user_id IS NULL AND o.created_at >= '2026-05-26' —— 这会先筛右表，再连左表，导致左表所有行都被过滤掉。正确写法是 ON u.id = o.user_id AND o.created_at >= '2026-05-26'。
- 如果右表连接字段没索引，
LEFT JOIN会退化成嵌套循环全表扫描，性能雪崩；NOT EXISTS至少不会放大中间数据量 - 当右表存在大量重复匹配（如一个用户有多笔订单），
LEFT JOIN会生成冗余中间行，再过滤，内存和 IO 开销更大
ANTI JOIN 节点——这要求子查询结构干净、索引到位、统计信息准确。写对语法只是起点，后面每一步都可能断链。
