alter table ... split partition 拆分分区需严格满足边界条件、规避 default 分区数据移动、显式更新全局索引并验证结果：拆分点必须在原分区上下界之间（如 p_2022 为 [2022-01-01, 2023-01-01)），含数据的 p_default 不可直接拆，须先归档；全局索引必须加 update global indexes，否则失效；拆分后须校验各分区数据归属与索引状态。
alter table ... split partition 是唯一可用方式，但直接执行大概率报错或锁表——关键不在“会不会”，而在“拆之前有没有看清边界、数据分布和索引状态”。
拆分点必须落在原分区上下界之间
ORA-14080 是最常见错误，本质是 AT 值超出了原分区定义的合法范围。
比如原分区 p_2022 定义为 VALUES LESS THAN (TO_DATE('2023-01-01', 'YYYY-MM-DD'))：
- 它的上界是 2023-01-01（不包含）
- 下界由前一分区决定，比如 p_2021 的上界是 2022-01-01，那 p_2022 实际覆盖 [2022-01-01, 2023-01-01)
- 所以只允许在 2022-01-01 到 2023-01-01 之间选拆分点
常见误操作：AT (TO_DATE('2021-06-01', ...)) ❌（低于下界）、AT (TO_DATE('2023-06-01', ...)) ❌（≥上界）
含数据的 DEFAULT 分区不能直接拆
p_default 看似“兜底”，一旦存了数据，SPLIT PARTITION 就会触发真实数据移动——锁表、慢、易引发 enq:TM-contention。
先确认是否有数据：
SELECT COUNT(*) FROM your_table PARTITION(p_default);如果结果 > 0： - 不建议硬拆，优先归档旧数据（如
INSERT INTO archive_table SELECT * FROM your_table PARTITION(p_default) WHERE ...）
- 或迁移出部分数据再拆，避免单次操作过大
- 拆分后新分区名别写反：INTO (PARTITION p_2023, PARTITION p_default) 中，p_default 必须保留为新兜底分区，否则数据就进错分区了
全局索引不加 UPDATE INDEXES 就会失效
只要表上有全局唯一索引（主键、唯一约束等），默认 SPLIT PARTITION 会让这些索引变成 UNUSABLE，后续所有 INSERT/UPDATE/DELETE 都失败。
必须显式加上：
ALTER TABLE log_archives SPLIT PARTITION p_default AT (...) INTO (...) UPDATE GLOBAL INDEXES;注意： -
UPDATE GLOBAL INDEXES 在 Oracle 11g 支持，但会延长执行时间
- 如果索引很大，且业务允许短时不可写，可考虑先 UNUSABLE 再重建，而非同步更新
- 别漏掉 GLOBAL 关键字，UPDATE INDEXES 默认只处理本地索引
拆分后务必验证分区数据归属
拆完不是结束，得立刻验证数据是否按预期落入新分区： - 查新分区行数：SELECT COUNT(*) FROM your_table PARTITION(p_2023);
- 抽样查数据边界：SELECT MIN(hire_date), MAX(hire_date) FROM your_table PARTITION(p_2023);
- 特别注意 DEFAULT 分区拆分后，剩余数据是否真落在新 p_default 里（而不是被误塞进 p_2023）
最容易被忽略的是：拆分语句里分区名顺序写反、AT 值用错日期格式（比如用 'YYYY/MM/DD' 却传入 '2023-01-01'）、以及以为加了 UPDATE INDEXES 就万事大吉，却没检查索引实际状态（SELECT status FROM dba_indexes WHERE index_name = 'YOUR_IDX';）。
