分区裁剪需显式在JOIN条件中包含分区字段且类型一致、无函数包裹；LEFT JOIN时右表分区条件必须写在ON中，否则退化为INNER JOIN且裁剪失效。

JOIN条件里必须显式包含分区字段

分区裁剪并不是表做了分区就会自动生效。它依赖优化器从查询逻辑中静态推导出可跳过的分区。

如果JOIN只写user_id = user_id，而两边都没有提到dt、event_time这类分区键，那么左表和右表都可能进行全表扫描。

常见误区：以为“JOIN on 主键 + WHERE 时间范围”就够了。实际上，右表的分区裁剪往往就在这里失效。

• 正确：LEFT JOIN t2 ON t1.user_id = t2.user_id AND t1.dt = t2.dt（两边dt等值对齐）
• 正确：INNER JOIN t2 ON t1.user_id = t2.user_id AND t1.event_time BETWEEN t2.start_time AND t2.end_time（区间匹配，且t2.start_time是其分区键）
• 错误：LEFT JOIN t2 ON t1.user_id = t2.user_id WHERE t2.dt = '2026-08-01'（WHERE过滤右表，在LEFT JOIN下会退化为INNER JOIN语义，且裁剪可能失效）
• 错误：JOIN t2 ON t1.user_id = t2.user_id AND DATE(t1.dt) = DATE(t2.dt)（函数包裹直接禁用裁剪）

LEFT JOIN时右表分区条件必须写在ON里

从语义上看，LEFT JOIN会保留左表全部记录，右表按条件匹配。

但数据库优化器只有在ON子句中看到右表的分区字段约束时，才会把它视为“可裁剪的驱动维度”。

如果把这个条件挪到WHERE子句里，它就会变成“必须非空”的条件。这相当于强制使用INNER JOIN，同时裁剪上下文也会丢失。

典型现象：执行计划里右表显示PARTITION RANGE ALL，或STARTS值远大于实际分区数。

• 正确：LEFT JOIN t2 ON t1.dt = t2.dt AND t2.dt = '2026-08-01'
• 正确：LEFT JOIN t2 ON t1.user_id = t2.user_id AND t2.dt BETWEEN t1.dt AND DATE_ADD(t1.dt, INTERVAL 7 DAY)（前提是t2.dt是分区键，且有对应索引）
• 错误：LEFT JOIN t2 ON t1.user_id = t2.user_id WHERE t2.dt = '2026-08-01'
• 注意：即使t2是小表，没写对位置照样全扫——裁剪不是看数据量，是看逻辑表达是否可推导

类型一致和无函数是硬性前提

分区裁剪是在优化器解析阶段完成的静态判断。任何让字段“不可比”的操作，都会让它放弃推理。

只要出现以下任一情况，裁剪就会中断：类型不匹配、隐式转换、函数包装。

• t1.dt STRING 匹配 WHERE t1.dt = '2026-08-01'（字面量带单引号）
• t1.dt STRING 匹配 WHERE t1.dt = 20260801（数字字面量触发隐式转换）
• WHERE DATE(t1.dt) = '2026-08-01'（DATE()函数彻底关闭裁剪能力）
• WHERE t1.dt + INTERVAL 1 DAY = '2026-08-02'（表达式破坏静态边界识别）
• 小陷阱：Hive/Spark 中STRING vs INT分区类型混用很常见，但只要JOIN两边不一致，裁剪就失效

确认裁剪是否真生效，只信EXPLAIN里的ACCESS PREDICATES

不要靠“查得快”或“感觉只用了几个分区”来判断。唯一可信的依据，是执行计划里是否明确写出了分区过滤条件的位置和范围。

重点关注两个点：

• ACCESS PREDICATES：真正用于定位分区的条件
• FILTER PREDICATES：扫描后再过滤，此时已经晚了

同时还要核对PARTITION RANGE是否为具体值，而不是ALL或ITERATOR。

• 健康信号：ACCESS PREDICATES ("dt" = '2026-08-01') + PARTITION RANGE SINGLE
• 危险信号：FILTER PREDICATES ("dt" = '2026-08-01') + PARTITION RANGE ALL
• 隐蔽坑：有些引擎（如Oracle）需开DBMS_XPLAN.DISPLAY_CURSOR并检查STARTS列——若值远大于你预期的分区数，说明裁剪没落地

实际调优中的关键判断

实际调优时，最容易忽略的一点，就是把分区键当成“可选条件”。

分区键不是锦上添花的索引，而是裁剪能否启动的开关。

哪怕其他所有条件都完美，只要分区字段没有在正确位置、以正确方式出现，就等于没分区。