必须用 alter table ... split partition 拆分含 maxvalue 的分区，因 oracle 禁止直接 add partition 到 maxvalue 分区（ora-14074）；需先查出 maxvalue 分区名及 high_value，再以 at 子句指定切分点，将原分区一分为二，其中一区保留原名作为新 maxvalue 分区，并务必加 update indexes 以维护全局索引。
不能直接 ADD PARTITION，必须用 ALTER TABLE ... SPLIT PARTITION 拆分含 MAXVALUE 的分区。 Oracle 不允许在已有 MAXVALUE 分区后追加新分区（会报 ORA-14074），唯一合规路径是把它“切开”——把原分区一分为二，其中一个是新历史分区，另一个保留为新的 MAXVALUE 分区。
确认当前 MAXVALUE 分区名和 HIGH_VALUE
拆分前必须精确知道目标分区名和它的上界值，否则语法报错或数据错位：
- 执行
SELECT PARTITION_NAME, HIGH_VALUE FROM USER_TAB_PARTITIONS WHERE TABLE_NAME = 'YOUR_TABLE'，找到HIGH_VALUE为MAXVALUE的那行，记下PARTITION_NAME（如P_MAX、POTHER或大小写敏感的p_max） -
HIGH_VALUE是 CLOB，显示可能被截断，但关键要看它是否真为MAXVALUE，而非某个具体日期字符串 - 若表按
DATE列分区，HIGH_VALUE通常对应TO_DATE('9999-12-31','SYYYY-MM-DD')或裸MAXVALUE；注意 Oracle 实际解析时对格式敏感
正确写出 SPLIT PARTITION 语句
语法核心是：指定切分点（AT 子句）、定义两个新区间、保留原分区名之一用于 MAXVALUE：
- 基本结构：
ALTER TABLE t_name SPLIT PARTITION p_max AT (TO_DATE('2024-07-01','YYYY-MM-DD')) INTO (PARTITION p_202406, PARTITION p_max) UPDATE INDEXES; -
AT值必须严格大于前一分区的HIGH_VALUE，且小于等于当前数据中该列最大值（否则部分数据会无法归入任一分区） - 新分区名（如
p_202406）不能与现有分区重名；第二个分区名（如p_max）必须与原分区名完全一致（含大小写），否则报ORA-14080 - 务必加上
UPDATE INDEXES，否则全局索引会失效（状态变为UNUSABLE），查询或 DML 可能失败
区分三种场景下的锁行为和风险
拆分操作是否阻塞业务，取决于 MAXVALUE 分区中是否有数据以及如何切分：
- 若
p_max当前为空（纯占位），SPLIT几乎瞬时完成，仅持短暂 DML 锁，业务无感 - 若
p_max有数据，但你把全部数据都切给新分区（即AT值设为远大于当前最大值），Oracle 仍可快速重定向元数据，不搬数据，锁时间短 - 若
p_max有数据，且AT值落在数据范围内（例如切出 2024-06 数据），Oracle 必须物理移动匹配的数据行，此时会对整个p_max加排他锁（TM锁），所有访问该分区的 INSERT/UPDATE/DELETE 都会等待，严重时引发enq: TM - contention
拆分后必须验证和清理
操作成功不代表万事大吉，几个容易忽略的点常导致后续问题：
- 检查
USER_IND_PARTITIONS中全局索引分区状态，确保没有UNUSABLE；如有，需ALTER INDEX ... REBUILD PARTITION - 确认新分区的表空间是否符合预期（默认继承原分区表空间，但若指定了
TABLESPACE子句则另当别论） - 运行
ANALYZE TABLE ... COMPUTE STATISTICS或DBMS_STATS.GATHER_TABLE_STATS，否则优化器可能因统计信息陈旧而选错执行计划 - 如果原
MAXVALUE分区长期堆积大量数据，拆分只是缓解，应建立定期维护机制（如每月自动拆分脚本），避免下次又面临同样锁压
真正麻烦的从来不是语法写不对，而是没意识到 AT 值选在数据中间时，Oracle 会实实在在地搬运每一行——这个过程既耗时又锁表，线上操作前必须评估数据量级和业务容忍窗口。
