子查询在分区表上易致空结果或性能差，主因是优化器提前物化子查询而丢失分区裁剪；应避免where中嵌套依赖分区键的子查询，改用join/lateral、预计算分区值或物化视图。
子查询在分区表上容易查出空结果？先看执行计划
分区表加子查询后数据对不上，八成是优化器把子查询提前物化了，没走分区裁剪。MySQL 8.0+ 和 PostgreSQL 都可能出现，但表现不同：MySQL 可能全表扫描 subquery，PostgreSQL 则可能把子查询当成独立 CTE 提前执行。
- 用
EXPLAIN FORMAT=TREE（MySQL）或EXPLAIN (ANALYZE, VERBOSE)（PG）确认子查询是否出现在分区扫描之前 - 避免在
WHERE中直接嵌套依赖分区键的子查询，比如WHERE dt IN (SELECT MAX(dt) FROM events)—— 这会让优化器不敢下推分区条件 - 改用
JOIN或LATERAL（PG）/JOIN LATERAL（MySQL 8.0.14+）显式绑定分区上下文
历史数据跨月分区，子查询里写 MAX(dt) 会慢得离谱
分区键是日期字段（如 dt），想查“每个分区最新一天的数据”，直接在子查询里算 MAX(dt) 很危险：它会触发全分区扫描，哪怕你只想要最近 3 个分区。
- 把动态分区范围提前算好，用
VALUES或临时表固化，例如：SELECT * FROM events WHERE dt IN ('2024-03-31', '2024-02-29', '2024-01-31') - 在支持列表分区或时间范围分区的引擎中（如 TiDB、StarRocks），优先用
SHOW PARTITIONS查出目标分区名，拼进IN条件，比子查询更稳 - 别信
SELECT MAX(dt) FROM events PARTITION(p202403)—— 某些版本不支持分区级子查询，直接报错ERROR 1210 (HY000): Incorrect arguments to PARTITION
INSERT ... SELECT 带子查询往分区表写数据，主键冲突却没报错？
往按 id 分区的表里批量插入时，如果子查询来源含重复 id，MySQL 可能静默去重（取决于 sql_mode 和存储引擎），而 Hive/Trino 会直接失败。这不是子查询的问题，是目标表分区策略和唯一性约束没对齐。
- 检查目标表是否真有
UNIQUE KEY或PRIMARY KEY—— 分区表上主键必须包含分区键，否则建表就报错 - 子查询里加
DISTINCT或GROUP BY是权宜之计，但掩盖了源头数据质量缺陷 - 用
INSERT IGNORE或ON DUPLICATE KEY UPDATE显式声明冲突行为，比靠子查询“自然过滤”更可靠
PostgreSQL 的 LATERAL 子查询比普通子查询更适合分区联合
当你要对每个分区做独立聚合再合并，比如“每个分区取 top 5 用户”，LATERAL 能让子查询看到外层的分区信息，避免反复扫描。
SELECT p.partition_name, t.*
FROM (SELECT partition_name FROM pg_partitions WHERE tablename = 'events') p,
LATERAL (SELECT user_id, COUNT(*) c
FROM events PARTITION (p.partition_name)
GROUP BY user_id
ORDER BY c DESC LIMIT 5) t;
注意：PARTITION 名不能拼接变量，PG 不支持动态分区名；实际要用 pg_class + pg_inherits 手动构造查询，或者换用 tablefunc 扩展的 crosstab。
复杂点在于分区名和查询逻辑耦合太紧，一旦分区策略从按月改成按天，所有 LATERAL 查询都得重写。这种场景不如用物化视图预聚合，子查询只是临时方案。
