EXCHANGE PARTITION能秒级加载数据是因为仅交换数据字典中的段指针而不移动实际数据；需源表与分区结构完全一致，包括列定义、约束及索引，否则报ORA-14097等错误。
EXCHANGE PARTITION 为什么能秒级加载数据
因为 exchange partition 不移动实际数据，只交换数据字典中的段（segment）指针 —— 类似 linux 的硬链接切换。只要源表和分区结构完全一致（列名、顺序、类型、null 属性、约束），oracle 就跳过数据拷贝，直接更新元数据。
常见错误现象：ORA-14097: column type or size mismatch in ALTER TABLE EXCHANGE PARTITION，本质是两边表的 DDL 看似一样，但隐式差异被忽略。
- 检查
USER_TAB_COLUMNS中DATA_TYPE、DATA_LENGTH、NULLABLE、DATA_PRECISION和DATA_SCALE必须逐列严格一致 -
VARCHAR2(100)和VARCHAR2(100 CHAR)被视为不同；NUMBER和NUMBER(10)也不等价 - 目标分区所属表如果有主键/唯一索引，源表必须有相同名称、相同列顺序的约束（哪怕只是 DISABLED）
如何安全执行 EXCHANGE PARTITION 归档流程
归档不是“把旧分区挪走”，而是用一个空表先承接分区数据，再把该表重命名或导出。关键在原子性和可逆性。
使用场景：每日按 DATE 分区的订单表，需将 P_20240501 归档为独立历史表。
- 提前建好归档表
orders_arch_20240501，结构与原表完全一致（包括SEGMENT CREATION IMMEDIATE） - 执行前加锁：
LOCK TABLE orders IN EXCLUSIVE MODE，防止并发 DML 导致交换中途失败 - 交换命令必须带
INCLUDING INDEXES和WITHOUT VALIDATION（验证会扫描全量数据，失去秒级意义） - 交换后立刻
RENAME源表，并确认USER_TAB_PARTITIONS中该分区已消失
示例：ALTER TABLE orders EXCHANGE PARTITION P_20240501 WITH TABLE orders_arch_20240501 INCLUDING INDEXES WITHOUT VALIDATION;
EXCHANGE PARTITION 容易踩的坑
最常被忽略的是统计信息和索引状态。交换后原分区的统计信息不会自动迁移到新表，索引也可能失效。
- 交换后
orders_arch_20240501的统计信息仍是空的，后续查询可能走错执行计划 —— 需手动收集：DBMS_STATS.GATHER_TABLE_STATS('SCHEMA','ORDERS_ARCH_20240501') - 如果原表有本地索引（
LOCAL），交换后对应索引分区会随分区一起转移，但状态变为UNUSABLE；全局索引则需指定UPDATE GLOBAL INDEXES，否则整个索引失效 - 分区表启用了行移动（
ENABLE ROW MOVEMENT）？交换本身不依赖它，但若后续要做SPLIT或MERGE，没开这个会报ORA-14099
MySQL / PostgreSQL 用户注意：没有原生 EXCHANGE PARTITION
MySQL 8.0+ 的 ALTER TABLE ... EXCHANGE PARTITION 仅支持 MyISAM 和 ARCHIVE 引擎，InnoDB 不支持。PostgreSQL 直到 16 版本才通过 ATTACH PARTITION + DETACH PARTITION 模拟类似流程，但需手动处理约束和索引。
替代方案实质是“重命名+约束同步”：
- MySQL InnoDB：用
RENAME TABLE切换表名，再用ALTER TABLE ... ADD PARTITION把空表挂回去（需提前DROP原分区） - PostgreSQL：先
ALTER TABLE old_table DETACH PARTITION p20240501，再ALTER TABLE p20240501 RENAME TO orders_arch_20240501，最后补上CHECK约束和索引
这些操作都不是元数据秒级，尤其 PostgreSQL 的 DETACH 在大表上会持有 AccessExclusiveLock，影响线上写入。
真正需要秒级切换的场景，别绕开 Oracle 的 EXCHANGE PARTITION —— 它的语义和实现是目前最接近“无感归档”的方案。其他数据库要么靠应用层双写兜底，要么接受几秒到几分钟的锁等待。
