对分区键使用函数会导致分区裁剪失效，如TRUNC(create_date)、TO_CHAR(create_date,'YYYY-MM')等；正确写法应保持分区键裸露，如create_date >= DATE '2025-01-01' AND create_date < DATE '2025-01-02'。
WHERE条件里对分区键用了函数
这是最常见也最容易被忽略的问题。比如分区键是create_date（DATE类型），但写成WHERE TRUNC(create_date) = DATE '2025-01-01'，优化器就无法推导出对应分区边界——TRUNC破坏了谓词的可下推性，裁剪直接失效。
- 类似情况还包括：
TO_CHAR(create_date, 'YYYY-MM')、EXTRACT(YEAR FROM create_date)、create_date + 1 - 正确写法应保持分区键裸露：用
WHERE create_date >= DATE '2025-01-01' AND create_date - 如果业务逻辑强依赖函数，可考虑建基于函数的虚拟列并将其设为分区键（需Oracle 11g+）
隐式类型转换让优化器“看不懂”分区键
当分区键是DATE，却拿字符串字面量去比，比如WHERE dt = '2025-01-01'，Oracle会隐式调用TO_DATE('2025-01-01')，而这个转换发生在运行时，计划生成阶段无法确定分区范围。
- 现象：执行计划里看不到
PARTITION RANGE SINGLE，只有FULL SCAN或RANGE ALL - 验证方法：查
PLAN_TABLE中OPERATION列是否含PARTITION START/STOP；没有就说明裁剪失败 - 修复方式：统一用显式类型，如
WHERE dt = DATE '2025-01-01'或WHERE dt = TO_DATE('2025-01-01', 'YYYY-MM-DD')
绑定变量未启用bind-aware或值不确定
预编译SQL中用WHERE dt = :v_date，但硬解析时:v_date无具体值，优化器只能按最宽泛范围估算，常退化为全分区扫描。
- 即使后续执行时传入具体日期，计划已定，不会重生成——这就是“计划固化”问题
- 启用
bind-aware cursor sharing可缓解，但前提是统计信息准确、且该SQL被多次执行触发自适应游标特性 - 更稳妥的做法：应用层拼接确定日期字符串；或改用存储过程，在
EXECUTE IMMEDIATE前先赋值再查 - 注意：
CURDATE()、SYSDATE这类非确定性函数在多数Oracle版本中也不支持静态裁剪
JOIN或子查询把分区过滤“藏”起来了
分区表参与JOIN时，如果分区键条件没放在驱动侧或被移到WHERE里，优化器可能放弃裁剪上下文。例如LEFT JOIN后把分区条件写在WHERE，实际变成INNER语义，且右表字段无法用于左表分区推导。
- 典型陷阱：
SELECT * FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE o.order_date = DATE '2025-01-01'—— 表面看有分区条件，但JOIN结构可能导致裁剪失效 - 子查询中用
IN (SELECT order_date FROM log WHERE ...)关联分区键，多数情况下无法静态推导分区范围 - 建议：分区过滤条件尽量写在最外层
WHERE；JOIN时确保ON包含等值分区键，并控制驱动表小、有索引
分区裁剪是否生效，不靠猜，只看执行计划里有没有PARTITION START和STOP这两行。所有“看似合理”的写法，只要破坏了优化器在硬解析阶段静态推导分区边界的能力，就会掉进全扫陷阱——而这个过程往往无声无息，直到慢查询报警才暴露。
