哈希分区不支持范围查询，必须全分区扫描；其核心是MOD(列值,分区数)导致数据离散无序，仅WHERE hash_key = ?等值条件可触发单分区访问，且需避免函数、隐式转换等破坏剪枝的行为。
哈希分区无法支持范围查询，必须扫描全部分区
哈希分区的核心机制是用 MOD(列值, 分区数) 计算目标分区，结果完全离散、无序。这意味着你查 create_date BETWEEN '2023-01-01' AND '2023-01-31' 时，Oracle 无法推导出哪些分区可能包含该时间范围的数据——因为日期值经哈希后已失去时间顺序信息。执行计划里会看到 PARTITION START 和 PARTITION STOP 显示为 ALL，实际就是全分区扫描。
常见错误现象：
- 明明建了哈希分区，
EXPLAIN PLAN却显示ACCESS FULL或扫描数十个分区 - 按时间范围或数值区间过滤的 SQL，响应时间与未分区表几乎无差别
- 分区键上建了局部索引，但查询仍不走索引（因分区剪枝失效，优化器放弃索引访问路径）
哈希分区键必须严格等值匹配，且不能有函数或隐式转换
只有 WHERE hash_key_column = ? 这种纯等值条件才可能触发单分区访问。一旦加了函数、类型转换或模糊匹配，剪枝立即失效。
容易踩的坑：
-
WHERE user_id + 0 = 12345—— 表达式导致无法使用分区键 -
WHERE user_id = '12345'—— 字符串与数字比较，触发隐式转换，TO_NUMBER('12345')包裹在分区键上 -
WHERE SUBSTR(user_id, 1, 5) = '12345'—— 函数操作彻底屏蔽分区剪枝 - 绑定变量类型与列定义不一致（如
NUMBER列传入VARCHAR2绑定值）
哈希分区不适合高基数低选择率的等值查询
即使写对了 WHERE user_id = 12345，性能也不一定比非分区表好。原因在于：
- 哈希分区本身不减少 I/O：单分区数据量可能仍很大，需读多个数据块
- 没有排序属性，无法利用有序性加速
ORDER BY或GROUP BY - 局部索引虽能配合剪枝，但若查询还需回表取大量字段，随机 I/O 开销反而上升
- 相比 B 树索引直接定位行，哈希分区多了一层“计算分区号 → 定位分区段 → 扫描该段”的间接过程
什么时候哈希分区才真正有用？
它只在一种场景下不可替代：高频、高并发、严格等值的点查，且数据天然倾斜严重（比如用户 ID 集中在某几个号段），而你又想靠哈希打散热点。
典型适用条件：
- 查询条件 100% 是
WHERE id = ?，从不出现范围、IN（多值）、LIKE或其他谓词 - 分区键基数极高（千万级以上），且分布相对均匀（避免哈希碰撞集中）
- 业务能接受分区数固定（增减分区需
ALTER TABLE ... SPLIT/MERGE PARTITION，锁表风险高） - 表同时存在大量 DML，需借助分区裁剪降低维护成本（如
TRUNCATE PARTITION清旧数据）
如果当前查询涉及时间范围、地域分组、模糊匹配或任意组合条件，哈希分区不仅没帮助，还会让优化器更难生成合理执行计划——这时候该换范围分区或复合分区，而不是硬扛。分区方式选错，比不分区还糟。
