必须显式指定OWNER，否则因DBA_TAB_PRIVS中TABLE_NAME非唯一且Oracle不自动推断schema，会导致查出多条无关记录、误判权限；还需注意大小写规则、GRANTEE为角色时需追溯成员及默认角色状态、访问权限不足时换用ALL_/USER_TAB_PRIVS视图。
必须显式指定 OWNER，否则结果不可信。 Oracle 不会自动按当前用户或登录上下文推断 schema，DBA_TAB_PRIVS 中的 TABLE_NAME 是非唯一字段——不同 owner 下可能有同名表（如 EMP 在 SCOTT、HR、OPS 下都存在），漏写 OWNER 会导致查出多条无关记录，甚至误判权限范围。
为什么直接 WHERE TABLE_NAME = 'EMP' 会出错
常见错误现象：执行 SELECT * FROM DBA_TAB_PRIVS WHERE TABLE_NAME = 'EMP' 返回几十行，但其中只有几条真正属于你要查的那张表。
- Oracle 默认不区分大小写地匹配
TABLE_NAME，但OWNER必须严格大写（除非建 schema 时用了双引号） -
GRANTEE可能是具体用户名、角色名，也可能是PUBLIC——后者意味着任意用户都能访问，需重点标出 -
GRANTABLE = 'YES'表示该权限带WITH GRANT OPTION，接收方可再授权，属于高风险配置，不能忽略
DBA_TAB_PRIVS 中 GRANTEE 是角色时怎么办
这条视图只存“谁被授了什么”，不反映“谁实际能用”。如果 GRANTEE 是角色（如 'APP_ROLE'），而你需要知道最终哪些用户能访问该表，不能停在这一步。
- 先查角色成员：
SELECT GRANTEE FROM DBA_ROLE_PRIVS WHERE GRANTED_ROLE = 'APP_ROLE' - 再确认这些用户是否将该角色设为默认角色：
SELECT DEFAULT_ROLE FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'USER1' AND GRANTED_ROLE = 'APP_ROLE'；若为'NO'，则需手动SET ROLE才生效 - 注意：
ADMIN_OPTION和DEFAULT_ROLE是两个独立字段，别混淆用途
查不到结果？先核对这三件事
90% 的“查不到”其实是权限视图访问或过滤条件问题，不是权限不存在。
- 当前用户没有
SELECT ANY DICTIONARY或SELECT_CATALOG_ROLE，无法访问DBA_TAB_PRIVS——改用ALL_TAB_PRIVS（只显示你有权访问的对象）或USER_TAB_PRIVS（仅查你自己被授的权限） -
OWNER写成了用户名而非 schema 名。例如：用户SCOTT创建的表，OWNER是'SCOTT'，不是'SYSTEM'或当前登录用户 - 表名默认大写，除非建表时用了双引号（如
"emp"），否则不能写成小写'emp'；权限名（如'select'）才大小写不敏感
容易被忽略的是 REFERENCES 和 ALTER 权限：前者允许在其他表上创建外键指向该表，构成隐式数据依赖；后者允许修改结构，比 SELECT 危险得多，却常被当作低危权限放行。
