Oracle不支持全局哈希索引；其全局索引仅支持RANGE或HASH分区方式，但底层均为B-Tree结构，HASH分区仅指索引分区策略，非索引类型，且不支持范围查询。
全局哈希索引在Oracle中不被支持
Oracle数据库本身不提供“全局哈希索引”这种索引类型。你查到的“TiDB 全局索引支持哈希分区”是TiDB的行为，不能套用到Oracle。Oracle的全局索引（GLOBAL INDEX）只允许按范围（RANGE）或哈希（HASH）方式分区，但注意：这里的“哈希分区”是指**索引自身按哈希规则分区**，而非索引类型为哈希索引；Oracle的全局索引底层仍是B-Tree结构。
换句话说：CREATE INDEX ... GLOBAL HASH 是合法语法，但它创建的是一个“哈希分区的全局B-Tree索引”，不是“哈希索引”。它不改变索引的查询能力——仍不支持范围查询，也不加速等值查询以外的操作。
为什么不能靠全局哈希索引优化非分区键查询
非分区键查询慢的根本原因，是缺乏分区剪枝 + 缺乏高效索引定位。全局索引能解决后者，但必须满足两个前提：
- 索引列要覆盖查询条件中的关键字段（比如
user_id），且该列有足够选择性 - 索引必须是全局的（否则局部索引无法跨分区查，除非查询也带分区键）
- 不能对索引列使用函数或隐式转换，否则索引失效（如
WHERE UPPER(name) = 'ABC'）
而哈希分区的全局索引，虽然物理上分散存储，但Oracle访问它时仍需先定位到对应哈希桶，再走B-Tree查找。相比范围分区的全局索引，它在等值查询上并无性能优势，反而可能因哈希分布不均导致热点分区；更关键的是，它完全不支持 >、BETWEEN、LIKE 'abc%' 等常见谓词。
真正有效的替代方案
面对非分区键查询（例如：按 user_id 查订单表，但表按 order_date 分区），应优先考虑以下组合：
- 建一个全局B-Tree索引：
CREATE INDEX idx_orders_user_id ON orders(user_id) GLOBAL;—— 这是最直接、最稳定的选择 - 若查询常带时间范围+用户ID，可建复合索引：
CREATE INDEX idx_orders_user_date ON orders(user_id, order_date) GLOBAL;，兼顾等值与范围 - 确保统计信息最新：执行
EXEC DBMS_STATS.GATHER_INDEX_STATS('SCHEMA_NAME', 'IDX_ORDERS_USER_ID');，否则优化器可能误判索引有效性 - 检查执行计划是否真用了索引：用
EXPLAIN PLAN FOR ...后查DBMS_XPLAN.DISPLAY，确认 OPERATION 是INDEX RANGE SCAN或UNIQUE SCAN，而非TABLE ACCESS FULL
别被“哈希”字眼迷惑——Oracle里真正扛非分区键查询重担的，从来都是全局B-Tree索引，不是哈希分区，更不是哈希索引。
容易忽略的维护陷阱
全局索引最大的代价不在查询，而在DML和分区维护上：
- 对分区表执行
ALTER TABLE ... DROP PARTITION时，若未加UPDATE GLOBAL INDEXES，全局索引会直接失效（STATUS = UNUSABLE） - 分区交换（
EXCHANGE PARTITION）同样需要显式更新全局索引，否则索引指向错误数据块 - 大量并发INSERT/UPDATE可能引发全局索引争用，尤其当索引键高度集中（如自增ID末几位相同）时，容易出现ITL等待
这些都不是语法写错的问题，而是上线后才暴露的运维断点。建完全局索引，一定要在测试环境模拟一次分区清理流程，验证索引状态和查询是否连续可用。
