分区表 prune 未命中即查询未能裁剪无关分区，引发全分区扫描和性能下降，主因是 where 条件中分区键被函数（如 date()）、类型转换或复杂计算包裹，须以裸列或确定性等值表达式形式出现。
分区表 prune 未命中，意味着查询没有成功裁剪掉无关分区，导致全分区扫描，性能大幅下降。核心原因通常是查询条件无法被优化器识别为可下推到分区裁剪逻辑的谓词。
分区键表达式不匹配
分区键在 WHERE 条件中必须以「裸列」或「确定性等值表达式」形式出现，不能包裹在函数、类型转换或复杂计算中。
-
错误示例：
WHERE DATE(created_at) = '2024-01-01'（DATE() 函数阻止 prune） -
正确写法：
WHERE created_at >= '2024-01-01' AND created_at - 其他常见干扰：
CAST(partition_col AS STRING)、IFNULL(partition_col, 'x')、partition_col + 0等都会中断 prune
查询条件含非确定性函数或参数
优化器无法在计划生成阶段确定分区范围时，会放弃 prune。
-
典型问题：
WHERE partition_col = CURRENT_DATE()、WHERE partition_col = ?（预编译参数未绑定值）、WHERE partition_col = (SELECT MAX(p) FROM meta) - MySQL 8.0+ 支持部分 CURRENT_* 函数 prune，但需确认版本与 SQL_MODE；PostgreSQL 对
CURRENT_DATE支持较好，但NOW()可能受限 - 使用变量/参数时，确保执行前已赋值且值可静态推导（如 MySQL 的
SET @p := '202401'; SELECT ... WHERE pt = @p;在某些版本可 prune，但不如字面量可靠）
JOIN 或子查询导致分区键信息丢失
当分区表参与 JOIN，且分区键未出现在驱动表的等值条件中，或被子查询包裹后无法传递过滤信息，prune 就会失效。
- LEFT JOIN 中，若分区表是被驱动表，且 ON 条件未包含其分区键的等值约束，通常无法 prune
-
WHERE id IN (SELECT partition_col FROM dim)—— 大多数引擎不会将子查询结果用于分区裁剪 - 建议改写为显式 JOIN：
JOIN dim ON t.partition_col = dim.val，并确保 dim.val 有索引或统计信息充分
元数据异常或统计信息滞后
分区信息未刷新、表结构变更后未重载分区定义、或统计信息过旧，都可能导致优化器误判可裁剪范围。
- Hive/Spark：执行
MSCK REPAIR TABLE或ALTER TABLE ... RECOVER PARTITIONS同步元数据 - MySQL：检查
INFORMATION_SCHEMA.PARTITIONS是否包含预期分区，确认PARTITION_DESCRIPTION值正确 - 所有引擎：运行
ANALYZE TABLE（或对应命令）更新统计信息，尤其在批量新增分区后 - 注意：某些引擎（如 Doris）要求手动
ADD PARTITION，仅建目录不会自动注册
定位是否 prune 成功，最直接方式是查看执行计划中的 Partitions 字段（MySQL）、Partition Expression（Doris）、或 Scan partitions 行（Spark SQL）。若显示 All、1000+ 或具体列出大量分区而非少数几个，即为未命中。
