直接重置表空间hwm不可能，因hwm属segment级；应优化具体表的hwm，先查user_tables.blocks与真实数据块数差距，需用dbms_stats收集统计信息并用rowid估算真实块数，若blocks远大于真实块数则存在优化价值。
直接重置表空间的高水位线（hwm）是不可能的——hwm 是按 segment（表、索引等对象）存在的，不是表空间级别的概念。你要优化的是具体表的 hwm，而不是整个表空间。
查表当前 HWM 占用块数是否异常
先确认问题是否存在，避免“以为慢，实为其他原因”。关键看 BLOCKS（HWM 下已分配块数）与实际数据占用块数的差距：
- 执行
DBMS_STATS.GATHER_TABLE_STATS收集最新统计信息，否则USER_TABLES.BLOCKS值可能严重失真 - 用
SELECT COUNT(DISTINCT DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID)) FROM table_name估算真实使用的数据块数 - 对比：若
USER_TABLES.BLOCKS是 50000，而真实使用块仅 200，说明 HWM 虚高，有优化价值 - 注意：
EMPTY_BLOCKS在 ASSM 表空间中恒为 0，不可依赖；NUM_ROWS和BLOCKS的比值过低（如NUM_ROWS / BLOCKS ）是典型信号
alter table ... shrink space 是最安全的在线方案
适用于 Oracle 10g 及以上、启用了自动段管理（ASSM）的表空间，且表上无 LONG 类型列：
- 必须先执行
ALTER TABLE table_name ENABLE ROW MOVEMENT，否则报错ORA-10636: row movement is not enabled - 执行
ALTER TABLE table_name SHRINK SPACE COMPACT：只整理 HWM 下碎片，不降低 HWM，可在线做 - 执行
ALTER TABLE table_name SHRINK SPACE：真正降低 HWM，并释放空间回表空间，但会短暂持有SSX锁，期间 DML 阻塞 - 执行后必须重建索引（
ALTER INDEX idx_name REBUILD ONLINE），否则索引中大量ROWID失效，查询走索引时出错 - 不支持 IOT 表、堆组织表含
LOB列、或启用了表压缩（Basic Compression）的场景
alter table ... move 更彻底但停机成本高
适用于所有表类型，包括含 LOB、IOT、压缩表，但需停业务窗口：
-
ALTER TABLE table_name MOVE会重写全部行到新块，HWM 彻底重置，且释放的空间可被其他 segment 复用 - MOVE 后原索引全部失效（
STATUS = UNUSABLE），必须逐个REBUILD，否则任何走该索引的查询报ORA-01502 - 如果要保留原表空间，加
TABLESPACE users；想迁移到更快磁盘，可指定新表空间 - MOVE 过程中表不可 DML，且会产生大量 redo 和临时段，需评估归档压力和 TEMP 空间
- 对大表，建议搭配
NOLOGGING（如MOVE NOLOGGING）减少日志，但意味着该操作不可恢复
为什么 truncate 不总是可行？
TRUNCATE TABLE 确实能把 HWM 归零，但它不是“重置”，而是“重建”：
- 它隐式提交、不可回滚，且会清空全部数据——你删的是内容，不是空间浪费
- 若表有外键被引用，需先
DISABLE约束，否则报ORA-02266 - TRUNCATE 后索引仍有效（不像 MOVE），但如果你只是删了部分历史数据，TRUNCATE 就完全跑偏了目标
- 分区表可考虑
TRUNCATE PARTITION，精准释放某几个分区的 HWM，这是生产中最常用且低风险的操作
真正容易被忽略的点是：HWM 优化后，如果应用仍频繁用 INSERT /*+ APPEND */，下次批量插入又会立刻把 HWM 拉高——得同步检查 ETL 或应用代码里的插入模式。另外，SHRINK 和 MOVE 对表上已有的物化视图日志、CDC 配置可能有影响，操作前务必验证复制链路是否中断。
