SQL子查询在WHERE中执行与否取决于其位置：左侧强制执行，右侧可能被前置条件短路跳过；但真正影响性能的是子查询是否关联及内部是否提前过滤，而非单纯书写顺序。
WHERE条件顺序影响子查询是否被提前剪枝
数据库默认从左到右评估布尔表达式，但子查询在WHERE中不是“普通条件”——它本身要先执行。当子查询写在AND左侧（如 EXISTS (subq) AND status = 'done'），引擎必须先完整执行EXISTS子查询，才能判断后续条件；而把它放在右侧（如 status = 'done' AND EXISTS (subq)），只要status不匹配，整行直接跳过，子查询根本不会触发。
这和普通字段比较不同：字段比较能短路，子查询不能短路——它是个独立执行单元。所以位置决定它“是否一定被执行”，而非“执行快慢”。
- 左侧子查询：强制执行，无论主表其他条件是否过滤掉该行
- 右侧子查询：可能被前面高选择性条件拦住，避免无谓调用
- 含
OR时更危险：status = 'done' OR EXISTS (subq)会让子查询对所有status != 'done'的行都执行一遍
IN子查询放WHERE末尾仍会全量扫描右表
IN子查询在WHERE中无论放前放后，只要没加限制，优化器通常会先执行完子查询再做主表匹配。比如 WHERE id IN (SELECT user_id FROM orders WHERE amount > 1000)，即使id有索引，子查询仍可能扫全表orders——因为IN语义要求先拿到全部右值集合。
真正起作用的是子查询内部是否提前过滤，而不是它在WHERE里的位置。
- 错误写法：
WHERE id IN (SELECT user_id FROM orders)→ 扫全表orders - 正确写法：
WHERE id IN (SELECT user_id FROM orders WHERE created_at > '2026-10-01')→ 子查询内加时间过滤，大幅减少结果集 - MySQL 5.7+ 对简单
IN可能做物化，但一旦子查询含GROUP BY或LIMIT，就大概率无法下推外部条件
EXISTS子查询位置影响不大，但写法决定是否提前终止
EXISTS本质是半连接，只要找到一行就返回TRUE，不依赖顺序。但它是否高效，取决于ON条件能否走索引、驱动表大小、以及是否存在关联字段缺失索引。
把EXISTS放在WHERE最前或最后，执行计划往往一样；但若写成WHERE NOT EXISTS且右表无索引，就会变成嵌套循环全扫，耗时飙升。
- 高效写法：
EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid')→user_id有索引，且status进一步剪枝 - 低效写法：
NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)→ 若orders.user_id没索引，每查一个u.id都要全表扫orders -
EXISTS里别用SELECT *，用SELECT 1即可，避免列解析开销
容易被忽略的关键点：子查询是否关联、是否可重用
非关联子查询（如 (SELECT MAX(price) FROM products)）只执行一次，放哪都一样；但关联子查询（如 (SELECT COUNT(*) FROM log l WHERE l.user_id = u.id)）每行都重跑，这才是性能黑洞的根源——位置只是表象，关联性才是本质。
很多人盯着“放前面还是后面”，却没意识到：如果子查询里l.user_id没索引，或者主表u.id是NULL，那它不仅慢，还可能返回错误结果。
- 确认关联字段是否有索引：没有就建，别靠顺序“优化”
- 避免在SELECT子句里写关联子查询，改用
LEFT JOIN + GROUP BY更可控 - MySQL 8.0+ 可考虑
LATERAL，但PostgreSQL兼容性更好，生产环境慎用
