子查询在WHERE中不一定慢，MySQL 8.0+/PostgreSQL对简单IN子查询有半连接优化；若含GROUP BY、ORDER BY或相关子查询则退化为嵌套循环，此时应改写为JOIN。
子查询在 WHERE 里跑得慢，是不是该换 JOIN？
不一定。MySQL 8.0+ 和 PostgreSQL 对 WHERE ... IN (SELECT ...) 类子查询做了半连接优化，但前提是子查询不带 GROUP BY、ORDER BY 或相关子查询（比如引用外层表字段）。一旦出现这些，优化器大概率放弃转换，直接走嵌套循环——这时候性能就崩了。
实操建议：
- 用
EXPLAIN看执行计划：如果出现DEPENDENT SUBQUERY或多层select_type=SUBQUERY，说明没被优化，优先考虑改写为JOIN - 若子查询只查单列且结果集小（IN 可能比
JOIN更快——因为避免了临时表和去重开销 - PostgreSQL 中，
IN (VALUES ...)比子查询快得多；MySQL 则建议用IN (1,2,3)预先展开，别依赖运行时子查询
LEFT JOIN + WHERE IS NULL vs NOT EXISTS，哪个不漏数据？
语义等价，但行为有坑。很多人用 LEFT JOIN ... WHERE right_table.id IS NULL 找“不存在匹配”的记录，结果发现 right_table 的字段本身允许 NULL，导致 IS NULL 判定失效——这不是语法错，是逻辑误判。
实操建议：
-
NOT EXISTS更安全：它只关心子查询是否返回行，不依赖字段值，天然规避NULL干扰 -
LEFT JOIN方式必须确保ON条件里用的是非空键（如主键或NOT NULL的外键），且WHERE判定的字段来自右表且定义明确 - SQL Server 对
NOT EXISTS生成更优计划；MySQL 5.7 前者可能比后者多一次索引扫描，但 8.0 差异已很小
子查询当派生表（FROM 子句）和 JOIN 混用时，索引还生效吗？
大概率失效。把子查询塞进 FROM 写成 (SELECT ... FROM t1 WHERE cond) AS dt，再跟其他表 JOIN，MySQL 会先物化这个子查询结果（生成临时表），默认无索引。哪怕原表 t1 上有完美索引，物化后也丢了。
实操建议：
- 优先把子查询逻辑上提，合并进主
JOIN链，比如把WHERE t1.x IN (SELECT y FROM t2)改成JOIN t2 ON t1.x = t2.y - MySQL 8.0+ 支持
MATERIALIZATION和DERIVED提示，但不如直接重写可靠 - PostgreSQL 的 CTE（
WITH）默认不物化，但加MATERIALIZED关键字后就跟 MySQL 行为一致——这时就得检查执行计划里有没有Materialize节点
UPDATE / DELETE 里嵌子查询，为什么提示 “You can't specify target table for update in FROM clause”？
这是 MySQL 特有报错：ERROR 1093 (HY000)，意思是不能在 UPDATE 或 DELETE 的 WHERE 子句中，直接从正被修改的同一张表查数据。不是语法错，是引擎限制。
实操建议：
- 最稳解法：用派生表包一层，例如把
WHERE id IN (SELECT id FROM t WHERE ...)改成WHERE id IN (SELECT * FROM (SELECT id FROM t WHERE ...) AS tmp) - PostgreSQL 和 SQL Server 没这限制，但 MySQL 5.7/8.0 都要绕
- 如果逻辑允许，用
JOIN重写通常更快：比如UPDATE t1 JOIN t2 ON t1.id = t2.t1_id SET t1.flag = 1
子查询和 JOIN 不是互斥选项，关键看优化器能不能把它们归一化。真正卡住性能的，往往是那些看起来“应该能优化”但实际触发了物化、相关子查询或隐式类型转换的地方——这些地方，EXPLAIN 里往往藏得不深，但一眼就能看到“Extra”列里的 warning。
