AT值必须严格落在原分区实际数据范围内且不与已有边界重叠；例如p_max存2023-03-01后数据，仅能用AT('2023-04-01')等合法值，AT('2022-12-01')将报ORA-14074错误。
拆分 RANGE 分区时，AT 值必须严格落在原分区范围内
直接拆分一个 partition p_max（即定义为 values less than (maxvalue) 的分区）是常见需求，但很多人误以为可以随意指定任意时间点——其实 at 值必须满足两个条件：它得在原分区实际数据的范围内，且不能与已有分区边界重叠。比如 p_max 当前存着 2023-03-01 之后所有数据，那你只能用 at ('2023-04-01') 这类值去切；若用 at ('2022-12-01')，oracle 会报 ora-14074: partition bound must be greater than that of the last partition。
-
AT值不是“新分区的上限”，而是“左闭右开”切口：原分区中 AT 的数据进第一个新分区，≥AT的进第二个 - 若原
p_max是空的（无数据），AT值仍需合法，否则 DDL 会直接失败，不因“没数据”而放宽校验 - 生产环境建议先查
SELECT MIN(col), MAX(col) FROM table PARTITION (p_max)，确认数据跨度再定AT
拆分 MAXVALUE 分区必须加 UPDATE INDEXes
对含全局索引（尤其是唯一索引）的表执行 ALTER TABLE ... SPLIT PARTITION，漏掉 UPDATE INDEXES 是最常导致服务中断的操作之一。一旦跳过这步，所有依赖该索引的 DML（如 INSERT、UPDATE）会立即报 ORA-01502: index 'xxx' or partition of such index is in unusable state。
-
UPDATE INDEXES不是可选优化项，而是强制保障索引可用性的必要子句 - 如果表有多个全局索引，该子句会一并维护全部；局部索引则自动重建，无需显式指定
- 大表拆分时，
UPDATE INDEXES会延长执行时间，但比事后手工ALTER INDEX ... REBUILD更安全可控
LIST 分区不能用 AT，必须用 VALUES 指定拆分键值组合
想把一个 LIST 分区（比如 channel2 VALUES ('6','7','8','9')）按业务含义拆开，别套用 RANGE 的 AT 写法——Oracle 会直接报 ORA-14055: VALUES clause is required for splitting a list partition。LIST 拆分本质是“键值集合重分配”，必须明确告诉数据库哪些值归哪边。
- 写法必须是
SPLIT PARTITION channel2 VALUES ('6','7') INTO (PARTITION channel2_1, PARTITION channel2_2) - 括号内
VALUES列出的键值，必须是原分区定义中包含的子集；剩余值自动归入第二个新分区 - 若原分区含
DEFAULT，拆分后未显式声明VALUES的那个新分区会继承DEFAULT行为
拆分后要立刻检查分区边界和索引状态
命令执行成功不代表万事大吉。尤其在凌晨批量操作后，第二天查询突然变慢或报错，往往是因为分区边界没对齐，或者索引虽“可用”但统计信息已失效。
- 查新分区范围：
SELECT partition_name, high_value FROM user_tab_partitions WHERE table_name = 'XXX'，确认high_value解析结果符合预期（比如是否真变成'2023-04-01'） - 查索引状态：
SELECT index_name, status, funcidx_status FROM user_indexes WHERE table_name = 'XXX'，确保没有UNUSABLE或DISABLED - 大表拆分后建议立刻收集统计信息：
DBMS_STATS.GATHER_TABLE_STATS，避免优化器误判分区剪枝效果
