在关系型数据库里，视图只是保存在数据字典中的一条查询定义，它本身不存数据。当我们需要做数据血缘追踪、权限审计或者SQL性能优化时，常常要弄清楚一个视图到底查了哪些底层物理表。很多初学者会直接去翻视图的创建SQL，用字符串匹配去找表名，这种做法遇到嵌套视图或者动态SQL就彻底失效。更可靠的方式是读取数据库暴露出来的元数据，也就是系统表或者信息模式里的依赖关系记录。
利用information_schema视图依赖表
MySQL和PostgreSQL都实现了SQL标准里的information_schema模式，其中VIEWS表存了视图定义文本，而KEY_COLUMN_USAGE或者VIEW_TABLE_USAGE则记录了视图和基表的引用关系。在PostgreSQL中，information_schema.view_table_usage会直接列出某个视图所依赖的表，不管视图是不是嵌套的，只要最终落到物理表上都会被展开。
我们可以通过一段简单的查询把指定视图的原始表名拿出来。下面这段SQL在PostgreSQL中运行，能返回视图my_view依赖的所有表及其所属模式：
SELECT
vtu.table_schema,
vtu.table_name
FROM information_schema.view_table_usage vtu
WHERE vtu.view_name = 'my_view'
AND vtu.view_schema = 'public'
ORDER BY vtu.table_name;
MySQL的information_schema没有view_table_usage这张表，但可以用KEY_COLUMN_USAGE间接关联，或者更直接地查information_schema.VIEWS里的VIEW_DEFINITION字段再做解析。不过更推荐用SHOW CREATE VIEW命令，它在结果里给出了完整创建语句，配合编程语言里的SQL解析器提取表名会更稳。
需要注意的是，information_schema的视图依赖信息在部分数据库里只记录直接依赖。如果视图A依赖视图B，而B依赖表C，那么A在view_table_usage里可能只出现B。这时就要写递归查询把依赖链一层层展开，才能拿到真正的物理表C。
通过系统专属视图与函数获取
SQL Server提供了更为直白的元数据函数sp_depends和系统视图sys.sql_dependencies、sys.dm_sql_referenced_entities。其中sys.dm_sql_referenced_entities可以传入一个视图名，返回它引用的所有实体，包括表、视图、函数，并且能区分是架构绑定还是非绑定依赖。
下面是在SQL Server里获取视图dbo.my_view底层表名的示例：
SELECT
referenced_schema_name AS schema_name,
referenced_entity_name AS table_name
FROM sys.dm_sql_referenced_entities('dbo.my_view', 'OBJECT')
WHERE referenced_class_desc = 'OBJECT_OR_COLUMN'
AND objtype = 'USER_TABLE';
Oracle虽然没有information_schema，但USER_DEPENDENCIES和ALL_DEPENDENCIES数据字典记录了对象之间的依赖。通过查询REFERENCED_TYPE为TABLE且NAME为视图名的记录，就能拿到原始表。这种方法和SQL Server思路一致，都是依赖数据库自己维护的依赖树，比解析DDL文本准确得多。
使用系统函数或专属视图的好处是，数据库在视图定义变更时会同步更新这些元数据，不需要人工去维护解析规则。缺点是语法不通用，从一种数据库迁移到另一种时要重写查询。因此在做跨库工具时，通常会封装一个适配层，对每种库走不同的元数据SQL。
递归展开嵌套视图依赖
实际业务里，视图套视图非常普遍。比如报表视图依赖聚合视图，聚合视图又依赖基础明细视图。如果只查一层，拿到的还是视图名而非表名。要解决这个，可以用递归公共表表达式（CTE）在元数据上做遍历。
以PostgreSQL为例，我们可以先把view_table_usage和views自关联，遇到被引用对象仍是视图的就继续向下查，直到引用的都是物理表为止：
WITH RECURSIVE dep AS (
SELECT
vtu.view_name,
vtu.table_name,
vtu.table_schema
FROM information_schema.view_table_usage vtu
WHERE vtu.view_name = 'my_view'
UNION ALL
SELECT
d.view_name,
vtu.table_name,
vtu.table_schema
FROM dep d
JOIN information_schema.views v
ON v.table_name = d.table_name
AND v.table_schema = d.table_schema
JOIN information_schema.view_table_usage vtu
ON vtu.view_name = v.table_name
AND vtu.view_schema = v.table_schema
)
SELECT DISTINCT table_schema, table_name
FROM dep
WHERE table_name NOT IN (SELECT table_name FROM information_schema.views);
这段递归查询先取出my_view直接引用的对象，然后在递归部分把其中属于视图的对象再展开一层，最终过滤掉仍然是视图的名字，留下的就是最底层的原始表。在SQL Server里可以用sys.dm_sql_referenced_entities配合递归CTE实现同样逻辑，只是字段名换成referenced_entity_name和referenced_class_desc。
对于超大库成百上千个视图互相引用的场景，递归查询可能比较慢，建议在测试环境先验证执行计划。如果依赖层级很深，也可以考虑用定时任务把展开结果落进一张血缘表，供在线查询直接使用，避免每次实时递归。
SQL视图元数据检索information_schema修改时间：2026-08-15 14:48:17