oracle不支持将非分区表直接转为哈希分区表，因物理结构差异导致必须重建；可行方案为dbms_redefinition（推荐，近在线）或导出重建；需注意分区数为2的幂、键列高基数及虚拟列限制。
不能直接 ALTER TABLE ADD PARTITION 把非分区表转成哈希分区表——Oracle 不支持该语法，强行操作会报 ORA-14056 或 ORA-14289 错误。
为什么不能在线转换？
Oracle 的分区表是建表时就确定的物理结构，非分区表的数据段（segment）没有分区元数据、没有分区键映射逻辑，数据库无法在不重建的情况下“打散”已有数据并重分布到多个哈希分区中。所谓“添加分区”只适用于原本就是分区表的对象。
- 尝试执行
ALTER TABLE t ADD PARTITION BY HASH(id) PARTITIONS 8→ 直接报错ORA-14289: cannot add partitioning to a non-partitioned table - 即使加了
ONLINE关键字，12c/19c/21c 均不支持该操作 - 分区键列（如
user_id）若存在 NULL 值，哈希分区会把所有 NULL 归入同一个分区，破坏均匀性——这在迁移前必须清理
可行路径只有两种：DBMS_REDEFINITION 或导出重建
两者都需停写或短时锁表，但 DBMS_REDEFINITION 支持大部分时间在线，更适合交易流水类业务表。
-
DBMS_REDEFINITION是首选：它通过中间影子表完成原子切换，主表在重定义期间仍可读写（DML 需要额外配置同步机制） - 步骤核心是：
CAN_REDEF_TABLE检查兼容性 →START_REDEF_TABLE启动（指定partition by hash(user_id) partitions 8）→SYNC_INTERIM_TABLE同步增量 →FINISH_REDEF_TABLE切换 - 注意：源表必须有主键或唯一约束；目标分区键列不能为
NULL；临时表空间需充足（哈希重分布过程产生大量排序/散列临时段） - 导出重建（
expdp+CREATE TABLE ... PARTITION BY HASH+impdp）适合维护窗口长、能接受小时级不可写场景，但更可控、无隐式同步风险
哈希分区建表时最容易踩的三个坑
哪怕用 DBMS_REDEFINITION，最终落地的分区表结构一旦写错，后续查询和维护成本陡增。
- 分区数没选 2 的幂次：比如写
PARTITIONS 6，Oracle 内部 MOD 运算会退化为除法，且某些版本会触发隐式重映射，导致数据倾斜——必须用4/8/16/32 - 分区键基数太低：例如用
status CHAR(1)（仅 'S'/'F' 两个值），8 个分区里实际只有 2 个有数据，其余空转，比不分区还慢 - 忽略虚拟列限制：Oracle 不支持对表达式哈希（如
PARTITION BY HASH(year(trade_date))），若业务强依赖多字段组合唯一，得先ADD VIRTUAL COLUMN v_key AS (user_id * 10000 + mod(trade_no, 100))，再以该虚拟列分区
真正麻烦的不是语法，而是数据重分布期间的事务一致性保障和分区键选择验证——上线前务必用真实数据量抽样跑 SELECT COUNT(*) FROM t PARTITION (SYS_P123) 确认各分区行数标准差
