SQL分区裁剪失效主因是优化器无法静态确认WHERE条件与分区键的确定关系；需确保分区字段为独立列引用、避免函数/表达式、显式类型匹配、IN/OR值确定、范围格式与分区名一致，并将过滤下推至原始表扫描层。
SQL分区裁剪失效，通常不是因为查询写错了，而是分区字段在WHERE条件中没被数据库真正“识别”为可下推的过滤条件。核心问题在于：数据库优化器必须能静态确认过滤值与分区键存在确定的、可计算的等价或范围关系，否则就会放弃裁剪，扫描全部分区。
分区字段必须是独立的列引用
如果WHERE条件中对分区字段做了任何计算、函数包装或表达式变形，裁剪大概率失效。
- 有效写法：WHERE dt = '2024-01-01'（dt 是 STRING 或 DATE 类型分区列）
- 失效写法：WHERE substr(dt, 1, 7) = '2024-01'（用了函数，无法反推具体分区值）
- 失效写法：WHERE dt || '-01' = '2024-01-01-01'（字符串拼接破坏了列的独立性）
- 注意：即使是类型隐式转换也可能干扰识别，比如WHERE dt = 20240101（dt 是 STRING 分区），Hive/Spark 可能不裁剪；应显式写成WHERE dt = '20240101'
IN 和 OR 条件需满足“确定性枚举”
多个值的过滤可以裁剪，但前提是每个值都明确对应一个（或一组）真实存在的分区，且不能含变量、子查询或NULL。
- 有效写法：WHERE dt IN ('2024-01-01', '2024-01-02', '2024-01-03')
- 失效写法：WHERE dt IN (SELECT distinct dt FROM dim_date WHERE flag=1)（子查询结果不可静态推导）
- 失效写法：WHERE dt = '2024-01-01' OR dt IS NULL（NULL 不属于任何分区，引入不确定性）
- 小提示：部分引擎（如 Hive 3+）支持动态分区裁剪（DPP），但需开启配置且依赖统计信息，不能默认依赖
BETWEEN 和范围条件要求类型与精度严格匹配
范围裁剪比等值更敏感。日期类分区尤其容易因格式、时区、类型不一致而退化为全扫。
- 有效写法（DATE 分区）：WHERE dt BETWEEN '2024-01-01' AND '2024-01-31'
- 常见失效：WHERE dt BETWEEN '2024/01/01' AND '2024/01/31'（格式不符，无法匹配分区名）
- 易忽略点：若分区是 dt STRING 但存的是 '20240101'，则BETWEEN '2024-01-01' AND '2024-01-31'完全不匹配——字符串字典序比较和日期逻辑完全不同
- 建议：始终用SHOW PARTITIONS table_name确认实际分区名格式，WHERE 中的字面量必须与之一致
JOIN 或子查询中分区字段未下推到扫描层
即使主表有分区字段，若它来自 JOIN 结果、LATERAL VIEW、或 CTE 中非直接读取的列，优化器常无法将过滤下推到底层扫描。
- 失效场景：SELECT * FROM (SELECT t1.dt FROM t1 JOIN t2 ON t1.id = t2.id) sub WHERE dt = '2024-01-01' → dt 已脱离原始分区表上下文
- 有效方式：把分区过滤尽量放在最外层对原始表的访问中，例如：SELECT * FROM t1 JOIN t2 ON t1.id = t2.id WHERE t1.dt = '2024-01-01'
- 验证方法：EXPLAIN EXTENDED 查看执行计划，确认 Filter Operator 是否出现在 TableScan 操作之前，且分区字段出现在 predicate 中
