IN子查询在PostgreSQL 16中并非自动优化的银弹，仍可能物化为临时表或退化为Nested Loop；性能取决于索引、数据分布与执行路径，须通过EXPLAIN ANALYZE验证Materialize/SubPlan节点、行数匹配度及值列表规模，并优先用VALUES JOIN替代超200项的IN列表。
IN子查询在PostgreSQL 16里仍不是“自动优化”的银弹
PostgreSQL 16 没有改变 IN 子查询的根本执行逻辑：它依然可能被物化为临时结果集，也可能退化为 Nested Loop，尤其当子查询含聚合、DISTINCT 或引用外层字段时。别指望版本升级就让 WHERE id IN (SELECT ...) 自动变快——性能取决于你是否控制住了索引、数据分布和执行路径。
先看执行计划，再决定要不要改写
用 EXPLAIN ANALYZE 查看实际行为，重点关注三类信号：
- 出现
Materialize节点 → 子查询被物化，但若结果集大（比如 >5000 行），内存压力和哈希构建开销会上升 - 出现
SubPlan或InitPlan→ 可能是相关子查询，每行都重执行，必须改写 - 外层扫描行数 × 子查询耗时显著不匹配 → 说明优化器误判了选择率，
ANALYZE表或调整default_statistics_target可能比改 SQL 更有效
值列表超 200 项时，别硬拼 IN，改用 VALUES JOIN
PostgreSQL 16 对 VALUES 的哈希连接支持更稳，比长 IN 列表更可控：
SELECT u.* FROM users u JOIN (VALUES (1), (2), (3), ..., (250)) AS v(id) ON u.id = v.id;
注意要点：
-
VALUES后的每个值必须单独一行括号，不能写成(1,2,3) - 主表
users.id必须有索引，否则 JOIN 也走 Seq Scan - 如果值来自应用层（如 API 返回的 JSON 数组），优先建临时表并加
PRIMARY KEY，再ANALYZE tmp_table让优化器知道行数准确
子查询返回空时结果消失？这是语义陷阱，不是性能问题
WHERE status IN (SELECT code FROM whitelist) 在子查询无结果时，整个条件求值为 FALSE，不是 NULL，所以查不到任何行——哪怕 status 字段本身合法。这不是慢，是错。
稳妥做法只有两种：
- 显式兜底：
WHERE EXISTS (SELECT 1 FROM whitelist) AND status IN (SELECT code FROM whitelist) - 用
UNION构造非空集合：status IN (SELECT code FROM whitelist UNION SELECT NULL WHERE FALSE)不推荐，语义混乱；更干净的是在应用层判断子查询是否为空，再动态拼 SQL
真正影响性能的，从来不是 IN 本身，而是你有没有让数据库避开全表扫描——索引、统计信息、执行路径，三者缺一不可。写完 SQL 后不跑 EXPLAIN ANALYZE，等于没调优。
