查 dba_ts_quotas 是最直接的入口，用于查看用户在各表空间的配额及已用空间；它不依赖 segment、不受空表干扰，结果稳定快速，但仅反映配额内使用量，无显式 quota 且具 UNLIMITED TABLESPACE 权限的用户不会出现其中。
查 dba_ts_quotas 是最直接的入口
想看“哪个用户在哪个表空间里占了多少”，dba_ts_quotas 是唯一能按用户 + 表空间粒度聚合的空间配额视图。它不依赖 segment 分析，也不受空表（segment_created = 'no'）干扰，结果稳定、响应快。
常见错误是只查 dba_segments —— 它漏掉没建段的对象（比如刚建好但没插入数据的表），也统计不到临时段、回滚段等非持久对象，导致总和对不上配额视图。
-
username和tablespace_name是联合主键，一行代表一个用户在某表空间的配额/已用情况 -
max_bytes为 -1 表示「无限制」，不是 null；bytes是当前已用字节数（含未分配但已预留的空间） - 注意：该视图只反映「配额内」使用量；若用户没被显式赋 quota，但有
UNLIMITED TABLESPACE权限，则不会出现在此视图中
组合 dba_users 获取默认表空间归属
有些用户没在 dba_ts_quotas 里出现，不代表没占空间 —— 他们可能靠默认表空间隐式写入。这时要关联 dba_users 的 default_tablespace 字段，补全「默认表空间下所有用户」的潜在占用范围。
容易踩的坑是直接用 WHERE username IN (SELECT username FROM dba_ts_quotas) 过滤用户，会丢掉这部分人。正确做法是用 UNION ALL 合并两部分：
- 来自
dba_ts_quotas的显式配额记录 - 来自
dba_users且default_tablespace非 SYSTEM / SYSAUX 的用户（SYSTEM 用户通常不计入业务空间统计）
注意：dba_users.default_tablespace 值可能为空或指向不存在的表空间，查询前建议先用 SELECT tablespace_name FROM dba_tablespaces 校验有效性。
用 dba_segments 按 owner + tablespace_name 聚合实际物理占用
如果需要验证「到底用了多少真实空间」，必须查 dba_segments。它反映磁盘上真实分配的 extents，但要注意单位换算和对象类型过滤。
关键点：
-
owner对应用户名，tablespace_name必须非 null（某些系统对象如 LOB 可能跨表空间，需额外处理） - 只统计
segment_type IN ('TABLE', 'INDEX', 'LOBSEGMENT', 'LOBINDEX')，排除 rollback、type2 undo 等临时/系统段 -
SUM(bytes)是原始字节数，除以1024*1024得 MB，但别四舍五入太早——聚合后再 round，避免小数累积误差 - 性能影响：大库执行慢，建议加
WHERE owner NOT IN ('SYS','SYSTEM','OUTLN')排除系统用户
为什么三个视图结果常不一致？
这不是 bug，而是 Oracle 空间管理的多层抽象导致的必然现象：
-
dba_ts_quotas.bytes包含已分配但尚未写满的 block（比如 insert 时预分配 extent） -
dba_segments.bytes只统计已实际写入数据的 extents，不含空闲块 -
dba_free_space统计的是空闲 extent，但它不感知 autoextensible 文件的可扩展上限
所以生产环境排查空间问题时，得按场景选视图：配额管理看 dba_ts_quotas，容量规划看 dba_data_files + dba_free_space，定位大表看 dba_segments。强行统一数值只会掩盖真正瓶颈。
