查高水位线必须先收集统计信息，因USER_TABLES.BLOCKS反映的是曾使用过的块数（即HWM位置），若未分析表则该值不准；需执行DBMS_STATS.GATHER_TABLE_STATS或ANALYZE TABLE；再结合BLOCKS、EMPTY_BLOCKS及DBMS_ROWID计算真实占用块数来评估碎片。
查高水位线必须先收集统计信息
直接查 USER_TABLES.BLOCKS 是不准的，因为 BLOCKS 字段反映的是“曾经使用过的数据块数”，即高水位线（HWM）位置，但它依赖统计信息是否最新。没分析过表，BLOCKS 可能是旧值甚至为 0。
必须先执行统计信息收集：
-
ANALYZE TABLE table_name COMPUTE STATISTICS（旧方式，仍可用） - 更推荐：
EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname => 'SCHEMA_NAME', tabname => 'TABLE_NAME')
注意：GATHER_TABLE_STATS 默认不收集列直方图，如需更精细评估碎片，可加 method_opt => 'FOR ALL COLUMNS SIZE AUTO'。
用 USER_TABLES 查 BLOCKS 和 EMPTY_BLOCKS
USER_TABLES 视图里两个关键字段就是判断 HWM 的核心依据：
-
BLOCKS：高水位线以下已格式化、至少曾被使用过的数据块数 → 即 HWM 位置 -
EMPTY_BLOCKS：分配给该段、但在 HWM 之上的空闲块数 → 这些块从未写入过数据
典型查询：
SELECT table_name, num_rows, blocks, empty_blocks, last_analyzed FROM user_tables WHERE table_name = 'YOUR_TABLE';
如果 BLOCKS 很大但 NUM_ROWS 很小，且 EMPTY_BLOCKS 接近 0，说明 HWM 下有大量已格式化但当前为空的块（即“内部碎片”），这是 delete 后未 shrink 的典型表现。
验证实际数据占用块数（绕过 HWM 陷阱）
BLOCKS 是 HWM 值，不代表当前真实数据占多少块。要算“真·活跃块数”，得按行实际分布来统计：
- 用
DBMS_ROWID提取每行所在数据块号 + 文件号去重计数：
SELECT COUNT(DISTINCT DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) || '-' ||
DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID)) AS used_blocks
FROM your_table;
这个结果才是当前数据真正散落在多少个物理块上。如果它远小于 BLOCKS（比如 42 vs 716119），就确认存在严重 HWM 偏高问题。
注意：该查询在大表上可能较慢，建议在业务低峰或加 WHERE ROWNUM <= 100000 抽样估算。
区分段级总空间和 HWM 级别空间
很多人混淆 DBA_SEGMENTS.BYTES 和 USER_TABLES.BLOCKS：
-
DBA_SEGMENTS.BYTES是分配给该段的**全部空间**（含 HWM 上下所有已分配区） -
USER_TABLES.BLOCKS是 HWM 位置，只含 HWM **以下**的块（已格式化块）
所以会出现：一个空表 DBA_SEGMENTS.BYTES 是 65536（即 8 块 × 8K），但 USER_TABLES.BLOCKS 是 8 —— 因为初始区已格式化，HWM 就在第 8 块之后。
真正要定位“浪费在哪”，得比对三者：DBA_SEGMENTS.BYTES（总分配）、USER_TABLES.BLOCKS × 8192（HWM 下空间）、used_blocks × 8192（真实占用）。差值越大，越值得 shrink。
EMPTY_BLOCKS > 0，也不能说明 HWM 可被自动下移 —— Oracle 永远不会自己回收 HWM 下的空块，除非你显式执行 SHRINK SPACE 或 MOVE。 
