直接用子查询过滤历史版本数据常导致查不到结果或性能崩塌，因优化器提前物化子查询使分区裁剪失效、索引无法下推；应改用LATERAL JOIN或预计算版本范围。
直接用子查询过滤历史版本数据，多数情况下会查不到结果或性能崩掉——因为子查询在 WHERE 里引用版本字段时，常被优化器提前物化，导致分区裁剪失效、索引无法下推、甚至触发全表扫描。
子查询 WHERE version = (SELECT MAX(version) FROM t) 为什么总为空？
这不是语法错，是执行逻辑被破坏了。当表按 version 分区（如 LIST 或 RANGE），而你在 WHERE 中写 version = (SELECT MAX(version) FROM t)，MySQL/PostgreSQL 往往会先执行子查询，拿到一个固定值，再拿这个值去查主表——但此时已丢失“按 version 分区”的上下文，优化器不敢下推条件，可能扫全分区甚至全表。
- 用
EXPLAIN FORMAT=TREE（MySQL）或EXPLAIN (ANALYZE, VERBOSE)（PG）看执行计划，如果子查询节点出现在Partitioned Table Scan之前，就坐实了这个问题 - 更隐蔽的情况：子查询里用了
GROUP BY或JOIN，哪怕只查一个分区，也可能因物化中间结果而绕过裁剪 - 某些引擎（如 TiDB v6.5+）对这类写法做了优化，但 MySQL 8.0.33 之前基本不优化，别信文档里的“自动重写”
用 LATERAL / JOIN LATERAL 替代相关子查询
当你需要“对每个业务主键，取它最新 version 的那条记录”，别写 (SELECT * FROM t2 WHERE t2.id = t1.id ORDER BY version DESC LIMIT 1) 这种相关子查询——它在分区表上极慢，且 MySQL 5.7 不支持 ORDER BY ... LIMIT 在子查询中。
- PostgreSQL 写法：
FROM t1 LEFT JOIN LATERAL (SELECT * FROM t2 WHERE t2.id = t1.id ORDER BY version DESC LIMIT 1) AS t2_latest ON true - MySQL 8.0.14+ 支持
JOIN LATERAL，语义一致；低于该版本只能改写为LEFT JOIN ... ON ... AND ...+ 外层ROW_NUMBER()窗口函数 - LATERAL 的关键优势：子查询能感知外层的分区键值，优化器可基于外层
id值精准定位到对应分区，避免跨分区扫描
预计算版本范围比实时子查询更稳
想查“所有主键在 v100～v105 之间的历史快照”，别依赖 WHERE version BETWEEN (SELECT MIN(version)...) AND (SELECT MAX(version)...)——两次子查询各扫一遍表，还可能因并发写入导致前后不一致。
- 先用
SELECT DISTINCT version FROM t WHERE version >= 100 AND version 查出实际存在的版本列表（加 <code>ORDER BY version保证顺序） - 把结果拼成
IN (100, 101, 102, 104, 105)再查主表，显式、可控、能走索引 - 若版本号是时间戳型（如
20240301），优先用SHOW PARTITIONS LIKE 't_%'（TiDB/StarRocks）或SELECT partition_name FROM information_schema.partitions（MySQL）直接读分区元数据，比查数据更快更准
别忽略 NULL 和三值逻辑对版本校验的影响
用子查询做版本存在性校验（比如“订单关联的配置版本必须有效”），WHERE config_version IN (SELECT version FROM configs) 遇到 configs.version 含 NULL 时整行消失——这是 SQL 三值逻辑的必然行为，不是 bug。
- 改用
EXISTS (SELECT 1 FROM configs WHERE configs.version = orders.config_version)，它对NULL不敏感，只关心是否匹配 - 若需允许
config_version IS NULL作为合法状态，得显式补条件：orders.config_version IS NULL OR EXISTS (...) - 聚合类版本校验（如“每个订单的 config_version 必须等于其创建时的最新版”）必须用
HAVING而非WHERE，否则过滤发生在分组前，逻辑就歪了
真正麻烦的从来不是怎么写子查询，而是子查询嵌在哪一层、是否暴露了分区键、有没有被优化器当成独立单元拎出来执行——这些细节在 EXPLAIN 里藏得深，但决定你查的是毫秒还是分钟。
