唯一可靠方式是查询 DBA_SYS_PRIVS 视图筛选 PRIVILEGE = 'UNLIMITED TABLESPACE'；DBA_TS_QUOTAS 不记录无限配额，因其仅存储显式设置的配额，而 UNLIMITED TABLESPACE 是系统权限，与表空间配额机制互斥。
直接查 dba_sys_privs 视图，筛选 privilege = 'unlimited tablespace' 即可 —— 这是唯一可靠方式。 不要依赖 dba_ts_quotas，它对无限配额不记录任何行。
为什么 DBA_TS_QUOTAS 查不到 unlimited 用户？
DBA_TS_QUOTAS 只存显式设置的配额（比如 ALTER USER u QUOTA 10M ON users）。一旦用户被授予 UNLIMITED TABLESPACE，Oracle 就绕过配额检查，该视图里压根不生成记录 —— 所以查 MAX_BYTES = -1 或空结果，都不能说明用户有没有无限权限。
- 现象：执行
SELECT * FROM DBA_TS_QUOTAS WHERE USERNAME = 'SCOTT'返回 0 行，不代表 SCOTT 没配额，只代表没显式设过 - 原因：
UNLIMITED TABLESPACE是系统权限，作用于所有表空间，和单个表空间的QUOTA机制互斥 - 验证必须走权限视图：
DBA_SYS_PRIVS或USER_SYS_PRIVS（当前用户视角）
正确查询语句及常见误判点
用以下 SQL 查所有拥有无限表空间权限的用户：
SELECT GRANTEE, ADMIN_OPTION FROM DBA_SYS_PRIVS WHERE PRIVILEGE = 'UNLIMITED TABLESPACE';
-
GRANTEE是用户名或角色名 —— 但注意：UNLIMITED TABLESPACE不能授给角色，所以这里GRANTEE几乎总是用户名 -
ADMIN_OPTION = 'YES'表示该用户还能把此权限再授给别人（极少见，需警惕） - 别漏权限：如果当前用户没
SELECT ANY DICTIONARY，查DBA_SYS_PRIVS会报错或无结果 —— 改用ALL_SYS_PRIVS（只显示你有权看到的）或USER_SYS_PRIVS（仅当前用户）
resource 角色带来的隐含权限容易被忽略
授予 RESOURCE 角色时，Oracle 会自动附带 UNLIMITED TABLESPACE 权限（即使 ROLE_SYS_PRIVS 里查不到这条记录）。这是 Oracle 的硬编码行为，不是角色定义的一部分。
- 验证方法：
SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE = 'RESOURCE' AND GRANTEE = 'U1'成立 → 几乎肯定有UNLIMITED TABLESPACE - 陷阱：如果
RESOURCE是通过中间角色（如APP_ROLE）间接授予的，则不会触发该隐含权限 —— 必须是直接授予用户 - 回收风险：执行
REVOKE RESOURCE FROM u1会连带收回UNLIMITED TABLESPACE，哪怕之前手动授过
真正麻烦的不是查不到，而是查到之后发现权限来自 RESOURCE —— 这意味着你改配额前得先确认角色继承链，否则改了 QUOTA 也无效。
