oracle中alter table drop column不生效是因为默认仅标记字段为不可见而非物理删除，需12c+加continue/checkpoint或11g用set unused+drop unused columns组合。
alter table drop column 在 oracle 中为何不生效
oracle 默认不真正删除字段，只是标记为不可见（invisible）并从数据字典中隐藏，但磁盘空间不会释放，旧数据仍保留在块中。这是最常被误以为“删了却还占空间”的根源。
- 必须显式加
DROP COLUMN后跟CONTINUE或CHECKPOINT才触发物理清理（12c+ 支持在线清理） - 11g 及更早版本只能用
SET UNUSED COLUMN+DROP UNUSED COLUMNS组合，否则字段残留且无法重建同名索引 - 执行前确认无依赖：检查
USER_DEPENDENCIES中是否存在视图、物化视图、函数索引引用该字段 -
DROP COLUMN是 DDL，会隐式提交，无法回滚；建议先在测试库用SET UNUSED观察一周再真正删除
使用 SQL Developer 可视化删除字段时的三个隐藏陷阱
图形界面看似点一下就完事，但底层生成的 DDL 很可能跳过关键步骤，尤其在跨版本迁移或字符集混合环境下。
- 默认勾选 “Drop column physically” 实际只对 12.2+ 生效；低于此版本会静默降级为
SET UNUSED，界面上不提示 - 若字段参与了函数索引（如
UPPER(name)），SQL Developer 不校验依赖，直接报错ORA-02443: Cannot drop constraint - nonexistent constraint - 可视化操作不记录完整语句到脚本面板，导致后续无法审计或复现；务必在执行前点击 “Show SQL” 复核，重点看是否含
ONLINE和CHECKPOINT
清理后表空间未收缩？别急着 shrink
即使字段已物理删除，高水位线（HWM）不会自动下降，SELECT COUNT(*) 结果不变，但 DBA_SEGMENTS.BYTES 也不减——这不是 bug，是 Oracle 的段管理机制决定的。
- 先查真实空间占用：
SELECT BLOCKS, EMPTY_BLOCKS FROM USER_TAB_STATISTICS WHERE TABLE_NAME = 'YOUR_TABLE'，比NUM_ROWS更准 - 用
ALTER TABLE ... SHRINK SPACE COMPACT前，确保表已启用行移动（ENABLE ROW MOVEMENT），否则报ORA-10636: row movement is not enabled - 如果表有 LOB 字段，
SHRINK SPACE默认不处理 LOB 段，得额外加SHRINK SPACE CASCADE，否则空间回收不彻底
Oracle 19c 后新增的 INVISIBLE COLUMN 误删风险
把字段设为 INVISIBLE 常被当作“软删除”，但很多人不知道：一旦执行 ALTER TABLE ... DROP COLUMN，哪怕该字段当前是 invisible 状态，也会被彻底清除，且不可通过闪回查询恢复。
-
DESC或USER_TAB_COLS查不到 invisible 字段，但USER_TAB_COLUMNS里HIDDEN_COLUMN = 'YES'仍存在，删之前务必查这个视图 - 应用代码若用了
SELECT *，字段 invisible 后可能因列序变化引发解析错误（尤其 JDBC PreparedStatement） - 导出时（expdp）默认不包含 invisible 字段，但若导出参数写了
INCLUDE=COLUMN，又没排除 invisible，则可能在目标库报ORA-00957: duplicate column name
字段删除不是原子动作，从标记 unused 到物理腾空间，中间隔着 checkpoint 频率、归档模式、undo 表空间大小三道坎。别信“删完就轻了”，得盯着 V$SESSION_LONGOPS 里的 Drop column 进度条走完才算数。
