优先用EXISTS判断值是否在子查询结果中，用IN判断值是否在明确的固定值列表中；IN处理动态子查询低效且对NULL不安全，EXISTS通过半连接和提前终止高效支持存在性判断。
子查询和JOIN没有绝对优劣，选哪个取决于你到底想表达什么逻辑、数据量多大、有没有索引，以及数据库版本是否支持半连接优化。
WHERE里用IN还是EXISTS
查“存在性”就别碰IN——比如“有订单的VIP用户”，写id IN (SELECT user_id FROM orders)会因orders.user_id含NULL而漏数据；EXISTS只看行是否存在，语义准、性能稳。
- 子查询结果确定非空、且固定小集合（如
IN (1,2,3)）——IN可读性好，MySQL 8.0+/PostgreSQL还能自动优化成半连接 - 子查询带
GROUP BY或聚合后可能出NULL——必须加IS NOT NULL或直接换EXISTS - PostgreSQL中
IN (VALUES (1),(2))比子查询快得多；MySQL建议提前展开，别依赖运行时子查询
相关子查询必须改写为JOIN
像SELECT name, (SELECT title FROM posts WHERE user_id = u.id ORDER BY created_at DESC LIMIT 1) FROM users u这种，每查一行users就执行一次子查询，1万行就是1万次扫描。优化器几乎不可能把它转成高效连接。
- 用
LEFT JOIN+ 窗口函数重写：先给posts按user_id分组排序，再JOIN取rn = 1的那条 - 确保
posts.user_id有索引，否则JOIN也白搭 - 别用
INNER JOIN替代——它会丢掉没发帖的用户，而原意是“没发帖就显示NULL”
FROM里的子查询（派生表）容易踩坑
写成FROM (SELECT id, name FROM users WHERE status = 'active') AS t看似干净，但MySQL 5.7及更早版本会强制物化成无索引临时表，哪怕原表users上有status索引也白费。
- 子查询只选几列、外层又只用其中1–2列——直接展开进主
JOIN链，避免字段冗余传输 - 子查询含
LIMIT、OFFSET或ROW_NUMBER()——保留为派生表是合理选择，逻辑无法平移 - 用
EXPLAIN看执行计划：出现Using temporary或Materialize节点，尤其结果集 > 1万行，就得警惕
UPDATE/DELETE里嵌子查询报错怎么办
MySQL报You can't specify target table for update in FROM clause不是语法错，是引擎限制：不能一边改users表，一边在WHERE里查同一张users表。
- 套一层派生表绕过：
UPDATE users SET status = 'archived' WHERE id IN (SELECT id FROM (SELECT id FROM users WHERE last_login - 用
JOIN改写更直观：UPDATE users u JOIN (SELECT id FROM users WHERE last_login - PostgreSQL和SQL Server没这个限制，但逻辑上仍建议拆成CTE或临时表，避免语义混淆
真正难的不是语法切换，而是判断哪部分逻辑必须保留子查询（比如标量子查询返回默认值），哪部分能安全下推到JOIN条件里——这得靠EXPLAIN盯住实际loops和actual rows，而不是凭经验猜。
