sqlite不支持full outer join和right join，是因其轻量嵌入式定位决定的设计取舍；可用join包括inner join、left join及逗号连接，替代full join需用union all拼接两个left join并显式处理null。
SQLite 的 JOIN 语法限制源于其设计定位
SQLite 不支持 FULL OUTER JOIN、RIGHT JOIN（或 RIGHT OUTER JOIN）等语法，不是 bug，而是明确的设计取舍。它的核心目标是轻量、嵌入式、单文件、零配置——所有功能都需服务于这个前提。FULL OUTER JOIN 的实现需要额外的哈希表或临时排序结构，会显著增加内存占用和执行路径复杂度，这与 SQLite 的“单线程、低内存、无后台进程”模型冲突。
哪些 JOIN 在 SQLite 中可用，哪些不可用
SQLite 支持 INNER JOIN、LEFT JOIN（等价于 LEFT OUTER JOIN），也支持隐式逗号连接（FROM t1, t2 WHERE t1.id = t2.t1_id）。但以下语法会直接报错：
-
FULL OUTER JOIN→ 报错：near "FULL": syntax error -
RIGHT JOIN→ 报错：near "RIGHT": syntax error -
CROSS JOIN虽然被识别，但实际行为等同于逗号连接，不强制执行笛卡尔积优化语义
注意：JOIN 关键字本身在 SQLite 中默认就是 INNER JOIN，不加修饰时不会报错，但也不等价于 LEFT JOIN。
替代 FULL OUTER JOIN 的可行写法
没有原生支持不等于不能实现逻辑等价。你可以用 UNION ALL 拼接两个 LEFT JOIN 结果：
一款AI工具，主要用于自动化从本地媒体及云编辑 API生成剪映草稿。当 Codex 需要扫描素材文件夹、请求编辑决策并...时使用，适合需要提升相关任务效率的用户。
SELECT t1.id, t1.name, t2.value FROM t1 LEFT JOIN t2 ON t1.id = t2.t1_id UNION ALL SELECT t2.t1_id, NULL, t2.value FROM t2 LEFT JOIN t1 ON t2.t1_id = t1.id WHERE t1.id IS NULL;
这个写法的关键点：
- 第一部分取 t1 全部 + 匹配的 t2 行（含 t2 为 NULL）
- 第二部分补上 t2 中未匹配的行（t1.id 为 NULL）
- 必须用
UNION ALL（非UNION），否则去重开销大，且可能误删合法重复行 - 字段对齐和 NULL 填充要显式写出，不能依赖
*
LEFT JOIN 的 ON 条件 vs WHERE 条件容易混淆
这是 SQLite 用户最常踩的坑：把过滤条件写在 WHERE 而非 ON，会导致 LEFT JOIN 实际退化为 INNER JOIN。例如：
-- ❌ 错误：t2.status = 'active' 在 WHERE 中，会过滤掉所有 t2 为 NULL 的行 SELECT t1.name, t2.value FROM t1 LEFT JOIN t2 ON t1.id = t2.t1_id WHERE t2.status = 'active'; <p>-- ✅ 正确：条件移到 ON 中，保留 t1 全部行 SELECT t1.name, t2.value FROM t1 LEFT JOIN t2 ON t1.id = t2.t1_id AND t2.status = 'active';</p>
SQLite 不做隐式修正，也不会警告；结果集变小了，但你可能根本意识不到 JOIN 已失效。
真正要注意的不是“为什么没实现”，而是“它本就不打算做这件事”。一旦你开始需要 FULL OUTER JOIN 或多层嵌套的 RIGHT JOIN，大概率说明你的数据规模或查询复杂度已超出 SQLite 的适用边界——该考虑 PostgreSQL 或 MySQL 了。
