时间戳范围过宽引发全表扫描，应避免直接用between或>=/
时间戳范围太宽导致全表扫描
直接用 BETWEEN 或 >=/ 匹配宽时间范围（比如跨年、跨十年），又没加前置剪枝，MySQL/PostgreSQL 很可能放弃索引走全表扫描——尤其当右表是历史冷表时，Buffer Pool 被反复刷脏，连带拖慢其他查询。
根本问题不是 JOIN 本身，而是优化器无法判断哪些分区/索引页真正需要访问。它看到 created_at BETWEEN '2000-01-01' AND '2030-12-31'，就默认“全都要”。
- 先确认执行计划：
EXPLAIN中type是ALL或index，rows接近表总行数，基本就是全扫了 - 检查被驱动表的关联字段是否建了复合索引，且顺序匹配查询模式，例如：按
created_at分区，则索引至少得是INDEX (created_at, other_id) - 避免在 JOIN 条件里对时间字段做运算：
DATE(created_at)、created_at + INTERVAL 1 DAY这类写法会让索引和分区裁剪同时失效
LEFT JOIN 时间范围条件必须写在 ON 子句里
这是最隐蔽也最致命的坑。一旦把时间判断挪到 WHERE，LEFT JOIN 就退化成 INNER JOIN，不仅性能没救，结果还错。
比如查每日订单并关联当天生效的价格策略，但某天无策略——本该保留订单、价格字段为 NULL，结果整行消失。
- 正确写法：
LEFT JOIN prices p ON o.order_time >= p.valid_from AND o.order_time - 错误写法：
LEFT JOIN prices p ON o.order_id = p.order_id WHERE o.order_time BETWEEN p.valid_from AND p.valid_until（p字段为NULL时整行被过滤） - PostgreSQL 可用原生
(a.start_date, a.end_date) OVERLAPS (b.start_date, b.end_date)，自动处理端点闭开与 NULL 安全
用 LATERAL 或 ROW_NUMBER() 替代暴力区间 JOIN
当你真正要的是“每个订单匹配的最新生效价格”，而不是所有重叠区间都拉出来——硬靠 BETWEEN 关联，会扫出大量无效中间行，JOIN 后还得再 GROUP BY 或 DISTINCT 去重，代价远高于预估。
- PostgreSQL 推荐：
LATERAL+LIMIT 1，确保每行只触发一次索引查找：LEFT JOIN LATERAL (SELECT * FROM prices p WHERE o.order_time BETWEEN p.valid_from AND p.valid_until ORDER BY p.valid_from DESC LIMIT 1) p ON true - MySQL 8.0+ 推荐：
ROW_NUMBER()先标序号再过滤：SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY valid_from DESC) AS rn FROM orders o JOIN prices p ON o.order_time BETWEEN p.valid_from AND p.valid_until) t WHERE rn = 1 - 注意：这两种写法的前提是
valid_from上有索引，否则ORDER BY仍会触发文件排序
分区表不是银弹，三要素缺一不可
建了 PARTITION BY RANGE (created_at) 不代表 JOIN 就快。分区本身不加速 JOIN，真正起效的是「分区裁剪 + 时间范围 WHERE 条件 + 关联列索引」三者同时满足。漏掉任一，分区反而增加元数据开销和执行不确定性。
- 分区键必须出现在 JOIN 条件或 WHERE 中的等值/范围表达式里，例如：
o.created_at = p.created_at或o.created_at BETWEEN p.start AND p.end - WHERE 必须显式限定时间下界和上界，如：
WHERE o.created_at >= '2024-03-01' AND o.created_at ，否则优化器无法确定裁剪哪几个分区 - 被驱动表的分区键字段必须有独立索引，且索引前导列就是分区键，例如分区是
RANGE (valid_from)，索引就得是INDEX (valid_from, valid_until)，不能只是INDEX (valid_until)
实际中最容易被忽略的是：你以为加了分区就万事大吉，结果执行计划里依然显示 type: ALL，而你还在调优 JOIN 写法——其实问题早在第一步就没满足分区裁剪前提。
