drop partition 彻底删除分区结构及元数据，仅适用于末尾范围/间隔分区或任意列表/哈希分区；truncate partition 仅清空数据、保留分区定义，所有分区类型均支持。
DROP PARTITION 和 TRUNCATE PARTITION 都能快速清理分区数据，但行为、影响和适用场景完全不同。选错会丢数据、锁表、或让应用出错。
删除分区（DROP PARTITION）会彻底移除分区结构
执行后，该分区连同其元数据、段、索引条目全部消失，无法回滚，且后续查询若涉及该分区范围可能报错（如 ORA-14074：partition must be the last partition in the range）。
- 仅适用于范围分区（
RANGE）和间隔分区（INTERVAL）的**最末尾分区**，或列表/哈希分区的任意分区（无顺序约束） - 释放空间，但不会触发任何触发器（
TRIGGER），也不写入 undo 日志 - 如果该分区上有本地索引（
LOCAL INDEX），对应索引分区自动删除；全局索引（GLOBAL INDEX）会失效，需手动ALTER INDEX ... REBUILD或加UPDATE GLOBAL INDEXES - 示例：
ALTER TABLE call_records DROP PARTITION BUS_DAILY_P1806;
截断分区（TRUNCATE PARTITION）只清空数据，保留分区定义
类似对整个表执行 TRUNCATE TABLE，但作用域限定在单个分区：数据秒删、空间回收、不记 undo、不可回滚，但分区本身还在，SQL 查询仍可命中该分区（只是返回空结果）。
- 所有分区类型都支持，包括范围、列表、哈希、间隔分区
- 本地索引分区保持有效；全局索引默认失效（除非加
UPDATE GLOBAL INDEXES子句） - 不会影响分区键范围定义，比如你
TRUNCATE PARTITION了202606分区，下个月新数据照常插入到202607分区，逻辑完全不受干扰 - 示例：
ALTER TABLE call_records TRUNCATE PARTITION BUS_DAILY_P1806;
容易踩的坑：全局索引失效和 MAXVALUE 分区风险
两个操作都可能让全局索引进入 UNUSABLE 状态，导致依赖该索引的查询直接失败（ORA-01502），而错误往往在业务高峰期才暴露。
- 务必在 DDL 后检查
SELECT index_name, status FROM dba_indexes WHERE table_name = 'CALL_RECORDS'; - 对含
MAXVALUE的范围分区，不能DROP PARTITION最后一个分区（即含MAXVALUE的那个），否则语句报错；但可以安全TRUNCATE PARTITION -
TRUNCATE PARTITION不释放表空间文件（datafile）物理大小，只重置高水位线（HWM）；真正收缩需后续ALTER TABLE ... SHRINK SPACE（且表需启用行移动）
DROP PARTITION（节省空间、彻底清理），清理测试数据或临时脏数据用 TRUNCATE PARTITION（保留结构、避免重建成本）。两者都不是事务性操作，没有中间状态——执行完就生效，没机会反悔。
