分区表join查询变慢甚至超时，根本原因是未触发分区裁剪，导致扫描大量无效分区；需确保join条件含分区字段、类型一致、无函数包裹，且left join时右表分区条件必须写在on中而非where后。
分区表JOIN时为什么查询变慢甚至超时
分区表JOIN慢，通常不是因为分区本身，而是查询没走分区裁剪（Partition Pruning），导致扫描大量无效分区。比如用 LEFT JOIN 时，右表的 WHERE 条件写在 ON 子句外，优化器就可能放弃裁剪。
- 确保JOIN条件中包含分区字段（如
dt、region_id），且两边类型一致（STRINGvsINT会抑制裁剪） - 避免在分区字段上做函数操作：用
dt = '2024-01-01'，别用DATE(dt) = '2024-01-01' - Hive/Spark SQL 中，
INNER JOIN默认支持裁剪；LEFT JOIN需右表分区字段出现在ON中，且不能被WHERE过滤（否则转为INNER语义）
如何确认分区裁剪是否生效
执行计划里看是否只读了目标分区——这是唯一可信依据，别信“看起来快”。不同引擎输出位置不同，但关键字段都叫 PartitionFilters 或 Partitions。
- Spark SQL：运行
EXPLAIN EXTENDED，搜PartitionFilters，确认右表有类似dt#123 = '2024-01-01'的条目 - Hive：用
EXPLAIN FORMATTED，查Partition Details段，看input partitions是否只含预期分区 - Trino/Presto：
EXPLAIN (FORMAT JSON)，找partitionedTableScan下的partitions字段
跨分区字段JOIN（比如按用户ID关联，但两张表分区键不同）怎么办
这种情况天然无法裁剪，但能通过预处理降低代价。核心思路是：把大表按JOIN键重分布，再和小表对齐分区，而不是硬扛全量扫描。
- 若右表较小（CREATE TABLE AS SELECT 把它按左表分区字段（如
dt）冗余一份，再JOIN - 若右表也大，考虑用
DISTRIBUTE BY（Spark）或CLUSTER BY（Hive）提前按JOIN键分桶，减少shuffle数据量 - 避免
SELECT *：只SELECT真正需要的列，尤其别带右表的分区字段（除非后续要用），否则可能干扰裁剪逻辑
MySQL / PostgreSQL 分区表JOIN的特殊坑
OLTP数据库的分区表JOIN更脆弱——优化器对分区感知弱，且不支持跨分区的统计信息下推。一个常见误判是：以为加了 WHERE 就自动裁剪，实际可能全表扫描。
- MySQL 8.0+：必须确保
JOIN条件中分区字段参与等值比较，且用IN或范围时要覆盖全部分区键（如RANGE COLUMNS(a,b)必须同时提供a和b） - PostgreSQL：分区键必须是
JOIN条件的一部分，且不能是表达式；用EXPLAIN ANALYZE看Actual Partitions行数，不是Planning Time - 两者都禁用
STRAIGHT_JOIN（MySQL）或ENABLE_SEQSCAN=off（PG）强行改计划——这会让分区裁剪彻底失效
