分区裁剪失效源于优化器无法静态推导分区键取值，关键在查询条件是否直接、确定、无函数包裹、类型严格匹配且位于外层WHERE中，UDF需显式声明确定性。
分区裁剪失效，本质是数据库优化器无法在执行计划生成阶段，静态确定目标数据落在哪些分区里。关键不在“有没有写分区字段”，而在于“能不能被准确识别和推导”。匹配是否成立，取决于查询条件与分区键之间的逻辑关系是否清晰、确定、无歧义。
分区字段必须直接出现在 WHERE 条件中
不能被函数包裹、不能参与计算、不能依赖运行时值。
- ✅ 有效：WHERE dt = '20240301'（dt 是 STRING 类型分区键）
- ❌ 失效：WHERE SUBSTR(dt, 1, 6) = '202403'（SUBSTR 破坏静态可推导性）
- ❌ 失效：WHERE dt >= DATE_FORMAT(NOW(), '%Y%m%d')（NOW() 是非确定性函数）
- ❌ 失效：WHERE dt = ?（预编译占位符，优化器编译时无具体值）
类型必须严格一致，避免隐式转换
即使语义相同，类型不匹配也会导致裁剪失败。常见于字符串与数字、带时区与无时区时间、不同精度的 datetime。
- ✅ 有效：分区键为 DATE 类型，WHERE start_date = '2024-03-01'
- ❌ 失效：WHERE start_date = '2024-03-01 00:00:00'（字符串字面量含时间部分，可能触发隐式转 CAST，部分引擎拒绝裁剪）
- ❌ 失效：分区键是 BIGINT（如年月日拼成 20240301），却用 WHERE dt = 20240301.0（浮点数，引发类型转换）
JOIN 和子查询中需显式保留在外层过滤
分区裁剪上下文容易在关联操作中丢失。优化器通常只对外层 WHERE 中明确约束分区键的条件做裁剪。
- ✅ 有效：LEFT JOIN t2 ON a.id = t2.id WHERE t2.ds = '20240301'
- ❌ 失效：LEFT JOIN t2 ON a.id = t2.id AND t2.ds = '20240301'（ON 中的条件对左表无裁剪作用，右表虽可能裁剪，但左表仍全扫）
- ❌ 失效：WHERE t1.id IN (SELECT id FROM t2 WHERE t2.ds = '20240301')（子查询结果不可静态推导，多数引擎放弃裁剪）
自定义函数需声明确定性
UDF 默认被视为非确定性，即使逻辑上是确定的，也会阻断裁剪。必须显式标记或全局启用确定性模式。
- ✅ 有效（MaxCompute）：UDF 类加 @UdfProperty(isDeterministic = true)
- ✅ 有效（MaxCompute）：SQL 前加 SET odps.sql.udf.ppr.deterministic = true
- ❌ 失效：直接使用未标注的 UDF 进行分区字段计算，如 WHERE ds = my_date_format('20240301')
