最准方式是查dba_segments并SUM(bytes)，因它反映段实际占磁盘空间（字节），需DBA权限；注意区分segment_type、过滤owner、结合tablespace_name和header_file定位物理位置。
查 dba_segments 看段大小排序
直接查 dba_segments 是最准的方式，它反映的是段（table、index、lobsegment 等）当前实际占用的磁盘空间，单位是字节。注意必须用 SUM(bytes) 聚合，因为一个段可能跨多个 extent，甚至多个 datafile。
执行前确认你有 SELECT_CATALOG_ROLE 或 DBA 权限，否则会报 ORA-00942: table or view does not exist。
SELECT segment_name, segment_type, owner, bytes/1024/1024 AS mb FROM dba_segments ORDER BY bytes DESC FETCH FIRST 10 ROWS ONLY;
区分 segment_type 避免误判大对象
结果里常见 LOBSEGMENT、INDEX、TABLE，但同一张表的主键索引和 LOB 列可能比表本身还大。比如一张存 PDF 的 DOCUMENTS 表，LOBSEGMENT 占 8GB，而 TABLE 只占 2MB —— 这时不能只盯着 TABLE 类型看。
建议加过滤或分组观察：
- 加
WHERE segment_type IN ('TABLE', 'INDEX', 'LOBSEGMENT')排除临时段、回滚段等干扰项 - 用
owner字段定位业务用户，避免被SYSTEM、SYSAUX下的系统对象刷屏 -
bytes是已分配空间，不代表数据量；空表建完没插数据也占 64KB（一个 extent）
注意高水位线（HWM）和真实数据量差异
dba_segments.bytes 显示的是分配空间，不是真实数据大小。如果表曾大量插入又删除，HWM 没下降，bytes 仍很高，但 COUNT(*) 可能为 0。
要查真实数据体积，得结合 dba_tables.num_rows * avg_row_len 估算，或用 DBMS_SPACE.SPACE_USAGE 查具体段的已使用块数。但这一步开销大，日常排查优先信 dba_segments。
容易踩的坑：
- 用
dba_extents替代dba_segments：它按 extent 拆行，SUM 不对，且不聚合段级信息 - 忘记除以 1024/1024，把字节当 MB 看，数值大三个数量级
- 在 RAC 环境下没加
INST_ID过滤，查到其他实例的 segment（虽少见，但跨实例 DBLINK 场景存在）
快速定位对应表空间和文件
光知道段名不够，还得知道它在哪——尤其是想收缩或迁移时。补上 tablespace_name 和 header_file 就很实用：
SELECT segment_name, segment_type, owner, tablespace_name,
bytes/1024/1024 AS mb, header_file
FROM dba_segments
ORDER BY bytes DESC
FETCH FIRST 10 ROWS ONLY;header_file 是 v$datafile.file#，可连查物理路径：
SELECT name FROM v$datafile WHERE file# = <header_file_value>;
真正麻烦的是：同一个表空间里混着几十个用户的段，清理前必须核对 owner 和业务归属，删错一个 INDEX 可能导致查询变慢十倍。
