段大小远大于count()结果是因为oracle以区为单位预分配空间，即使只插1行也至少分配64kb，且区一旦分配即计入段大小，而count()仅统计实际行数。
段大小为什么总是比 count(*) 结果大得多
因为段（segment）不是按行精确分配空间的，而是以区（extent）为单位预分配的。哪怕只插 1 行数据，oracle 也会先分配一个最小区（默认通常是 64kb 或更大），后续增长也按区倍增。所以段大小反映的是“已分配的存储容量”，不是“已使用的数据体积”。
DBA_SEGMENTS 和 DBA_TABLES 的 BYTES 字段差异来源
DBA_SEGMENTS.BYTES 显示段当前占用的总空间（所有已分配区之和），而 DBA_TABLES.BLOCKS 或估算的 NUM_ROWS × AVG_ROW_LEN 只反映逻辑数据量。两者不等是常态，不是异常。
- 区一旦分配就计入段大小，即使里面大部分块是空的（比如高水位线 HWM 以下但未被写满的块）
- 表上存在已删除但未
SHRINK SPACE的空间，仍属于段的一部分 - 索引段、LOB 段、ITL 插槽、块头开销等元数据也占空间，但不计入行数据统计
如何查清“多出来的空间”到底在哪
重点看区分配模式和高水位线位置，而不是直接对比 BYTES 和 COUNT(*)：
- 用
SELECT * FROM DBA_EXTENTS WHERE SEGMENT_NAME = 'YOUR_TABLE' AND OWNER = 'SCHEMA'查每一块区的起始块号和大小 - 用
ANALYZE TABLE your_table COMPUTE STATISTICS后查DBA_TABLES.EMPTY_BLOCKS和AVG_SPACE，确认空闲块比例 - 执行
SELECT BLOCKS, NUM_ROWS, AVG_ROW_LEN FROM DBA_TABLES WHERE TABLE_NAME = 'YOUR_TABLE'，手动估算理论最小空间：NUM_ROWS × (AVG_ROW_LEN + 20)（+20 是块头和行头粗略开销）
自动段管理（ASSM）下区大小不固定带来的偏差
在 ASSM 表空间中，Oracle 会动态选择区大小：小段用 64KB 区，变大后切到 1MB，再大可能到 8MB。这意味着刚插入几千行的小表，段大小可能已是 1MB —— 不是因为数据多，而是最小分配单元变了。
- 建表时不显式指定
STORAGE(INITIAL 64K)，实际初始区大小由表空间的INITIAL_EXTENT和段类型决定 - 频繁 DML 后未做
ALTER TABLE ... SHRINK SPACE COMPACT，会导致区碎片化，DBA_SEGMENTS.BYTES持续虚高 - 分区表每个分区都是独立段，
DBA_SEGMENTS里会看到多个同名段条目，别误加成一个
段的真实大小永远是“已向表空间申请并锁定的区总和”，不是“有多少字节存了有效数据”。想压低段大小，关键不在删数据，而在控制区分配节奏和及时回收空闲空间。
