DBeaver 7.0.0+ 支持视图依赖查看，但完整性取决于数据库和驱动：PostgreSQL 通常准确；MySQL 依赖 VIEW_DEFINITION 解析，易因截断或动态SQL失效；SQL Server 需权限且不支持加密视图。
在 DBeaver 中直接查看视图依赖的基表（MySQL / PostgreSQL / SQL Server）
DBeaver 从 7.0.0 版本起，在表/视图对象上原生支持「依赖关系」（Dependencies）视图，但该功能是否可用、显示是否完整，取决于数据库类型和 JDBC 驱动对系统元数据的暴露能力。
实际操作中，**不是所有数据库都能自动列出完整的基表依赖**。例如：
- PostgreSQL：通常能正确展示
pg_depend关联的基表和列； - MySQL：依赖
INFORMATION_SCHEMA.VIEWS和解析VIEW_DEFINITION字段，但若视图定义被截断（如超长 SQL）、含变量或动态拼接，DBeaver 就无法准确提取； - SQL Server：依赖
sys.dm_exec_describe_first_result_set或sys.sql_expression_dependencies，需权限足够且视图未加密（WITH ENCRYPTION会完全屏蔽依赖）。
打开方式：右键目标视图 → “编辑” 或 “查看依赖项”（菜单文字因版本略有差异），切换到 Dependencies 标签页即可。注意：该标签页只在连接成功且驱动支持时才出现。
手动查 VIEW_DEFINITION 是最通用的兜底方法
当 Dependencies 标签页为空或不显示时，直接读取视图定义是最可靠的方式——它不依赖驱动元数据接口，而是执行标准 SQL 查询。
执行以下语句（以 PostgreSQL 为例）：
SELECT viewname, definition FROM pg_views WHERE viewname = 'your_view_name';
MySQL 用户用：
SELECT TABLE_NAME, VIEW_DEFINITION FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_view_name';
关键点：
-
VIEW_DEFINITION字段内容是纯文本，可能含换行、注释、别名，需人工识别FROM和JOIN后的真实表名； - 如果视图嵌套了其他视图，依赖是递归的，DBeaver 不会自动展开，必须逐层查；
- 某些数据库（如 Oracle）会把定义存为
CLOB，DBeaver 默认只显示前 4000 字符，需右键字段 → “打开大对象”才能看全。
为什么“查找引用该表的所有视图”比“查视图依赖”更难？
DBeaver 的 Find references 功能（右键表 → “查找引用”）在多数数据库中**仅对约束、外键、存储过程生效，对视图基本无效**。原因很实在：
- 视图定义是字符串，数据库本身不维护“某张表被哪些视图引用”的反向索引；
- 扫描全部视图定义做全文匹配开销大，DBeaver 不默认启用；
- 即使你手动写 SQL 去
LIKE '%table_name%'，也会误匹配字段名、注释、别名甚至字符串常量。
真正可行的做法是：用 DBeaver 连接后，在 SQL 编辑器中运行自定义扫描语句，例如 PostgreSQL：
SELECT schemaname, viewname, definition FROM pg_views WHERE definition ILIKE '%your_table_name%';
但务必人工核对结果——这是唯一能兼顾准确性和可控性的路径。
容易忽略的兼容性细节
不同数据库对视图依赖的“粒度”支持差异很大，直接影响你能看到什么：
- PostgreSQL 可精确到列级依赖（比如知道视图只用了
users.id而非整张表），DBeaver 的 Dependencies 标签页会显示列名； - SQL Server 若视图含
SELECT *，则依赖分析会标记为“不明确”，DBeaver 就不会列出具体列； - SQLite 完全不提供依赖元数据，DBeaver 对其视图只能查
sqlite_master.sql字段，且无自动解析。
如果你正在排查一个生产环境中的视图变更影响范围，不要只信 Dependencies 标签页的“绿色勾选”——它可能漏掉嵌套视图、同义词（synonym）或跨 schema 引用。最稳妥的动作，永远是导出所有相关视图的 VIEW_DEFINITION，用文本搜索+人工确认。
