left join + where 右表主键 is null 是查找左表有而右表无记录的唯一可靠方式；必须用右表主键或not null字段判空，避免误用可空字段导致错判，且需为右表关联字段建索引以保障性能。
LEFT JOIN + WHERE 右表字段 IS NULL 是最直接有效的写法
想查“A表有但B表没有”的记录，LEFT JOIN配合WHERE b.id IS NULL就是标准解法。它不依赖子查询嵌套，执行计划清晰，数据库优化器也容易命中索引。
常见错误是写成WHERE b.id = NULL——SQL里=无法判断NULL，必须用IS NULL。另外，ON条件里的字段类型要严格一致，比如a.user_id是VARCHAR而b.id是INT，隐式转换可能让匹配静默失败。
- 确保
b.id是关联用的主键或外键字段，别错用b.name这类非唯一字段 - 在
b.id上建索引能显著提速，尤其当B表很大时 - 如果B表关联字段允许NULL（比如没设
NOT NULL约束），IS NULL会把“业务缺失”和“数据存了NULL”混在一起，得先加AND b.id IS NOT NULL过滤掉脏数据
NOT EXISTS 更安全，尤其当右表字段可能为 NULL
当B表的关联字段本身允许NULL时，LEFT JOIN可能产生误判：哪怕存在匹配行，只要那行的b.id是NULL，WHERE b.id IS NULL就会把它当成“缺失”。NOT EXISTS绕过了这个陷阱，语义更精确。
关键点在于子查询必须相关——即WHERE里要写pc.countryid = c.countryid这种引用外层表的条件。漏掉就变成独立子查询，性能崩盘。
一款AI数据处理工具，主要用于用于查询 Massive 市场数据端点的 Bash CLI 封装和 OpenClaw 技能，适用于 Codex 或 OpenClaw 代理从 shell 调用，适合需要提升相关任务效率的用户。
- 子查询里用
SELECT 1而不是SELECT *，减少数据搬运 -
pc.countryid字段必须有索引，否则NOT EXISTS也会慢 - 别用
NOT IN替代，只要子查询结果含一个NULL，整条WHERE就恒为UNKNOWN，结果集为空
嵌套子查询查缺失序列号？先确认有没有 NULL
用NOT IN (SELECT id FROM t)查断号，常返回空结果——不是逻辑错，而是t.id里有NULL。只要子查询吐出一个NULL，整个NOT IN表达式就失效。
第一步永远是检查：SELECT COUNT(*), COUNT(id) FROM t。如果两个值不等，说明存在NULL，必须先清理或加WHERE id IS NOT NULL过滤。
- 改用
NOT EXISTS可避开NULL问题，但要注意子查询是否关联外层 - 如果序列范围已知（如1–1000），生成全量序列再
LEFT JOIN更可靠，比如用WITH RECURSIVE seq(n)或MySQL变量模拟 - MySQL 5.7以下没CTE，靠多表
UNION拼数字表时，务必保证左右两边SELECT字段数、顺序、类型完全一致，否则UNION报错ERROR 1222
FULL OUTER JOIN 用于双向比对，MySQL需手动拼
要同时看到“A有B无”和“B有A无”，就得用FULL OUTER JOIN。但MySQL不支持，硬写会报ERROR 1064。PostgreSQL、SQL Server、Oracle原生支持；SQLite靠LEFT JOIN + RIGHT JOIN + UNION模拟。
模拟时最容易翻车的是字段对齐：两部分SELECT的列数、类型、顺序必须一致，且最好显式列出字段名，别用*。加个来源标记字段（如'a_only'）能避免后续归因混乱。
-
UNION ALL比UNION快，只要确认两边结果天然不重叠 -
ON条件写在JOIN后，千万别错写进WHERE，否则FULL OUTER JOIN退化成INNER JOIN - 真正定位“谁丢了”，还得靠
WHERE a.id IS NULL或WHERE b.id IS NULL单独筛，别试图用OR合并，逻辑易缠绕
LEFT JOIN + IS NULL覆盖80%场景；NOT EXISTS适合关联字段可能为空的严苛环境；序列号类缺失优先生成全量再左连——复杂点不在语法，在你是否先确认了数据里有没有NULL、字段类型对不对、索引建没建。
