子查询不等价于集合操作但可模拟集合行为，仅当返回多行单列且外层使用in、any/some、all时具备集合语义；否则易报错或逻辑错误，真正集合运算应优先用union/intersect或join。
子查询不等价于集合操作，但可模拟集合行为
MySQL 中的子查询本身不是标准 SQL 定义的集合操作（如 UNION、INTERSECT、EXCEPT），它本质是「嵌套的 SELECT 语句」，执行时机和语义取决于上下文。只有当子查询出现在 IN、ANY/SOME、ALL 或与 = 配合且返回单值时，才可能被优化器当作集合式逻辑处理——但这只是语义近似，底层仍按行逐查或物化临时表。
哪些子查询能安全当作集合用？
真正具备集合语义的子查询需满足：返回**多行单列**，且外层使用集合感知的操作符。否则容易报错或逻辑错误。
-
WHERE col IN (SELECT id FROM t2)✅ 可视作“属于集合”判断 -
WHERE col = ANY (SELECT id FROM t2)✅ 等价于IN -
WHERE col > ALL (SELECT val FROM t2)✅ 表示“大于所有值”，隐含全集比较 -
WHERE col = (SELECT id FROM t2)❌ 若子查询返回多行，直接报错Subquery returns more than 1 row -
SELECT * FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.x = t1.y)❌ 是相关子查询，属布尔逻辑，非集合运算
嵌套子查询的集合行为陷阱
多层嵌套时，MySQL 不会自动去重或排序，集合特性完全依赖写法。比如：
SELECT name FROM users
WHERE id IN (
SELECT user_id FROM orders
WHERE amount > 100
AND user_id IN (
SELECT id FROM users WHERE status = 'active'
)
);这个结构看似“集合交集”，但实际执行中：
- 内层
(SELECT id FROM users WHERE status = 'active')若未加DISTINCT，重复id会导致外层IN重复匹配（虽不影响结果，但浪费计算） - MySQL 8.0+ 可能将中间结果物化为临时表，但无索引，大表嵌套易慢
- 不能用
INTERSECT替代，因为 MySQL 直到 8.0.31 才支持INTERSECT，且不支持在子查询中嵌套INTERSECT
想真正做集合运算，优先用 UNION / INTERSECT 而非子查询
如果目标是合并、求交、求差，硬套子查询反而绕路。例如“找出在订单表和收藏表都出现过的用户ID”：
-- 推荐：显式 INTERSECT（MySQL 8.0.31+） SELECT user_id FROM orders INTERSECT SELECT user_id FROM favorites;
-- 兼容旧版：用 INNER JOIN 更清晰稳定 SELECT DISTINCT o.user_id FROM orders o INNER JOIN favorites f ON o.user_id = f.user_id;
而用子查询写成 WHERE user_id IN (SELECT ...) 套 WHERE user_id IN (SELECT ...)，既难读又无法利用索引下推，还容易漏掉 NULL 处理（IN 对 NULL 永远返回 UNKNOWN）。
嵌套越深，越要警惕执行计划里是否出现 DEPENDENT SUBQUERY 或 MATERIALIZED —— 这些不是集合操作的标志，而是性能告警灯。
