子查询不能真正突破SQLite的JOIN限制；它仅是语法替代，无法模拟FULL/RIGHT JOIN语义，且易致数据遗漏、性能下降和维护困难。
子查询不能真正“突破”连接限制，它只是换了一种表达方式；但用错场景反而会让查询更慢、更难维护。
为什么不能靠子查询绕过JOIN限制
SQLite不支持FULL OUTER JOIN，也不支持RIGHT JOIN，这是语法层面的硬性限制。有人试图用子查询模拟右连接效果，比如写成：SELECT * FROM table2 WHERE id IN (SELECT table2_id FROM table1)。这看似“绕过了”，实则丢失了LEFT JOIN中保留table2空匹配行的能力——子查询返回的是值集合，不是带NULL的关联结果集。
更关键的是，这种写法在table1里table2_id有重复或为NULL时，行为和LEFT JOIN完全不同，容易引发数据遗漏或误匹配。
哪些子查询能安全替代简单JOIN
仅当满足以下全部条件时，才建议用子查询代替INNER JOIN或LEFT JOIN：
-
IN子查询只用于存在性判断（如WHERE x IN (SELECT y FROM t)），且子查询结果集小、可索引 - 主表过滤条件强，子查询能被提前剪枝（例如外层加了
WHERE status = 'active'） - 子查询不依赖主表字段（即非关联子查询），否则SQLite可能无法优化执行计划
- 你明确接受子查询无法返回
JOIN中的额外列（比如不能同时拿到table1.name和table2.desc）
关联子查询的性能陷阱
像SELECT name, (SELECT COUNT(*) FROM orders WHERE orders.user_id = users.id) FROM users这类关联子查询，在SQLite中是逐行执行的——每查一个users.id，就跑一次子查询。如果users有10万行，等于执行10万次COUNT。
正确做法是改写为LEFT JOIN + GROUP BY：
SELECT u.name, COUNT(o.id) FROM users u LEFT JOIN orders o ON o.user_id = u.id GROUP BY u.id, u.name
前提是orders.user_id上有索引。没有索引时，两种写法都慢，但关联子查询更不可控。
真要模拟外连接？用UNION比子查询靠谱
SQLite虽不支持FULL OUTER JOIN，但可用UNION拼接两个LEFT JOIN结果：
SELECT a.id, a.val, b.val AS b_val FROM a LEFT JOIN b ON a.id = b.id UNION SELECT b.id, NULL, b.val FROM b LEFT JOIN a ON a.id = b.id WHERE a.id IS NULL
注意：UNION会去重，若需保留重复行，必须用UNION ALL；且所有SELECT的列数、类型、顺序必须严格一致，否则报错SELECTs to the left and right of UNION do not have the same number of result columns。
比起嵌套多层子查询，这种写法更易读、更易加索引、也更容易被SQLite的查询优化器识别。
最常被忽略的一点：SQLite的子查询是否走索引，完全取决于外层查询条件能否下推。别光看SQL长得像，得用EXPLAIN QUERY PLAN确认实际执行路径——很多你以为“优化了”的子查询，执行计划里还是SCAN TABLE。
