sqlite 不支持 full outer join，需用 left join + right join + union all 模拟；但存在 null 键漏数据、性能差等问题，且无法通过 pragma 或语法变通解决。
SQLite 不支持 FULL OUTER JOIN，直接写会报错
SQLite 从 3.0 到最新版（截至 2026 年）仍不支持 FULL OUTER JOIN 语法。你写 FULL OUTER JOIN 或 FULL JOIN，SQLite 解析器会直接拒绝，报错 ERROR: near "FULL": syntax error。这不是版本升级就能解决的限制——它是 SQLite 的设计取舍，不是 bug。别指望加个 PRAGMA 或改写成 OUTER JOIN 就能绕过。
用 LEFT JOIN + RIGHT JOIN + UNION ALL 拼出等效逻辑
这是最通用、兼容所有 SQLite 版本的替代方案，但必须严格对齐字段和过滤逻辑：
- 两个子查询的列数、顺序、类型必须完全一致，否则
UNION ALL会触发ERROR 1222: The used SELECT statements have a different number of columns - 右表独有部分必须用
WHERE left_table.id IS NULL显式筛选，不能省略——否则交集行会被重复计入两次 - 推荐统一用
LEFT JOIN模拟RIGHT JOIN，避免表序混乱：比如SELECT ... FROM table_b b LEFT JOIN table_a a ON a.id = b.id等价于table_a RIGHT JOIN table_b - 过滤条件不能写在外部
WHERE，必须塞进各自子查询的ON或内部WHERE；例如查“已发货订单及其用户”，o.status = 'shipped'要放在右连分支的WHERE里，且加a.id IS NULL
示例（合并 users 和 orders）：
SELECT u.id, u.name, o.order_id, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id UNION ALL SELECT u.id, u.name, o.order_id, o.amount FROM orders o LEFT JOIN users u ON u.id = o.user_id WHERE u.id IS NULL;
连接键含 NULL 时，LEFT+RIGHT 拼接会漏数据
SQL 标准中 NULL = NULL 判定为 UNKNOWN，所以当两表都有 id IS NULL 的记录时，LEFT JOIN 和 RIGHT JOIN 都不会匹配它们——而原生 FULL OUTER JOIN 会把这类双方都为 NULL 的行当作“匹配”保留。你的拼接结果里这部分数据就彻底消失了。
补救办法有限：
- 提前用
COALESCE(id, -1)或类似方式把 NULL 转为占位值，再参与连接（前提是业务允许且占位值不冲突） - 或分三步查：先取交集（
INNER JOIN），再分别查左独有（LEFT JOIN WHERE right.id IS NULL）、右独有（RIGHT JOIN WHERE left.id IS NULL），最后UNION ALL三者——但这手动拆解更易出错
大表慎用，性能比原生差一个数量级
SQLite 执行这个拼接方案时，实际跑两次全量 JOIN（一次左连、一次右连），再做一次内存合并。如果两表各 10 万行，IO 和 CPU 开销接近原生 FULL OUTER JOIN 的 2–3 倍。EXPLAIN 显示 SEARCH TABLE 出现两次，且中间结果无法利用索引下推。
优化要点：
- 确保连接字段（如
user_id）有索引：CREATE INDEX idx_orders_user_id ON orders(user_id); - 若只关心“缺失数据”，比如“有订单但无用户”，直接用
SELECT * FROM orders o LEFT JOIN users u ON u.id = o.user_id WHERE u.id IS NULL，比拼全外快得多 - 实在要全量比对，考虑在应用层读取两表主键集合，用 Python/Java 做集合运算再查详情，反而更可控
真正难处理的不是语法写法，而是 NULL 键语义和性能衰减——这两点在测试小数据时完全看不出来，一上生产环境就暴露。
