union等集合运算符不能直接用于where或in子句，因其非单值表达式；必须包裹为带别名的派生表（如select * from (select a from t1 union select b from t2) as t），且列数、类型须严格对齐。
嵌套查询里不能直接用 UNION 或 INTERSECT 作为子查询的主体，但可以把它们放在 FROM 子句中当派生表用——这是最稳妥、兼容性最好的写法。
为什么不能在 WHERE 或 IN 里直接写 UNION？
因为 UNION、INTERSECT、EXCEPT 是集合运算符，不是表达式，不能返回单值。像 WHERE id IN (SELECT a FROM t1 UNION SELECT b FROM t2) 这种写法在多数数据库（如 PostgreSQL、SQL Server）会报错，提示“subquery must return only one column”或“syntax near UNION”。MySQL 8.0+ 虽支持，但语义容易误读：它其实把整个 UNION 当作一个结果集，而 IN 只能接受单列子查询。
常见错误现象：
-
ERROR: syntax error at or near "UNION"（PostgreSQL） -
Incorrect syntax near the keyword 'UNION'（SQL Server，尤其在子查询未加括号或缺少别名时） - MySQL 返回结果但逻辑不符——比如你以为是“找同时满足两条件的 ID”，实际执行的是“找在任一 UNION 结果里的 ID”
正确写法：把 UNION/INTERSECT 包进括号并起别名
必须把集合运算的结果当作一个临时表（派生表），再参与外层查询。关键点是：加括号、显式 AS 别名、列名对齐。
例如，要查“既是销售员又是技术支持，且薪资 > 8000 的员工”：
SELECT e.name, e.salary FROM employees e INNER JOIN ( SELECT emp_id FROM sales_team INTERSECT SELECT emp_id FROM support_team ) AS qualified ON e.emp_id = qualified.emp_id WHERE e.salary > 8000;
要点：
-
INTERSECT和UNION都必须包裹在(...)中，否则解析失败 -
AS qualified不可省略（MySQL 5.7+ 允许省略，但 SQL Server / PostgreSQL 强制要求） - 两个
SELECT的列数、类型、顺序必须一致；若原表字段名不同，可在子查询中统一用别名，如SELECT id AS emp_id FROM t1 - 不建议在子查询里用
ORDER BY—— 派生表本身无序，排序会被忽略，除非配合LIMIT或窗口函数
UNION ALL 在嵌套过滤中的实际用途
当你要“合并多个来源的候选 ID，再统一过滤”时，UNION ALL 比 UNION 更高效，也更可控。
比如：从三个历史分区表中找出所有活跃用户 ID，再查其最新登录时间：
SELECT u.id, MAX(l.login_time) AS last_login FROM ( SELECT user_id AS id FROM users_2024_q1 UNION ALL SELECT user_id AS id FROM users_2024_q2 UNION ALL SELECT user_id AS id FROM users_2024_q3 ) AS u JOIN login_logs l ON u.id = l.user_id GROUP BY u.id;
注意：
- 这里用
UNION ALL是因为不需要去重（ID 本就唯一），避免额外的哈希去重开销 - 如果某张分区表可能含重复 ID，且你确实需要全局去重，才换用
UNION，但性能下降明显 - 某些旧版 SQLite 或 Access 不支持子查询中用
UNION，此时只能改用OR或临时表
INTERSECT 的等价替代方案（兼容性兜底）
Oracle 用 MINUS，老版本 MySQL 不支持 INTERSECT，PostgreSQL 支持但语法严格。遇到不支持时，用 EXISTS 嵌套更通用：
-- 想实现：SELECT id FROM t1 INTERSECT SELECT id FROM t2 SELECT t1.id FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.id);
这个写法在所有主流数据库都有效，且执行计划通常和 INTERSECT 接近。但要注意：
-
EXISTS不自动去重，如果t1有重复id，结果也会重复；需加DISTINCT显式控制 - 若
t2.id有 NULL，EXISTS仍可能返回意外结果（NULL 不等于任何值），而INTERSECT会按标准 SQL 处理 NULL 相等性 - 复杂多表交集时，嵌套
EXISTS层级变深，可读性下降，不如直接升级数据库或用 CTE 拆解
真正容易被忽略的是列定义一致性——哪怕只是 INT 和 BIGINT 的隐式转换，在某些数据库（如 SQL Server）中会导致 UNION 报错，而不是静默转换。动手前先 DESCRIBE 或 SELECT TOP 1 看两表字段类型，比调半天错误更有用。
