如何编写脚本检测SQL视图依赖，避免因基表删除导致视图引用问题？

本文共计797个文字，预计阅读时间需要4分钟。

《关于图像引用的注意事项：

查哪些视图依赖已删除的基表

SQL Server 不会自动清理失效视图依赖，sys.dm_exec_describe_first_result_set 可快速筛出当前无法解析的视图定义。但更稳妥的是用 sys.sql_expression_dependencies 结合基表实际存在性做交叉验证：

• 先查出所有引用了指定表名（比如 'Orders'）的视图：SELECT referencing_id, referencing_entity_name FROM sys.sql_expression_dependencies WHERE referenced_entity_name = 'Orders' AND referenced_class = 1
• 再对结果中的每个 referencing_id，检查它是否还指向真实对象：SELECT OBJECT_ID('dbo.v_order_summary') 返回 NULL 就说明该视图底层已断链
• 注意：视图可能引用的是同义词、临时表或跨库三段名（如 OtherDB.dbo.Customers），这类需额外用 PARSENAME() 拆解并分别验证

MySQL 中视图失效的静默表现与检测盲区

MySQL 的视图在基表删除后仍能 SHOW CREATE VIEW 成功，但执行 SELECT * FROM v_orders 会直接报 Table 'db.Orders' doesn't exist。关键问题是：它不记录依赖关系到系统表，INFORMATION_SCHEMA.VIEWS 里查不到引用链。

• 唯一可行方式是解析 VIEW_DEFINITION 字段里的 SQL 文本，用正则粗筛表名（例如匹配 FROM\s+`?(\w+)`?），再逐个 SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='Orders' 核实
• 不要依赖 SHOW DEPENDENCIES —— 这个命令在 MySQL 8.0+ 仍不存在，属于常见误传
• 如果视图定义含子查询或 JOIN 多表，单靠文本匹配容易漏判；此时应优先在开发阶段禁用「隐式创建视图」，强制用 CREATE ALGORITHM=MERGE 显式声明，减少运行时解析歧义

修复前必须确认的两个事实

不是所有“基表不存在”都该立刻重建表——可能本就是下线流程的一部分。

• 查 sys.tables 或 information_schema.TABLES 确认该表是否真被 DROP，还是仅被重命名（sp_rename 不更新视图依赖）
• 检查最近一周的部署记录或 DDL 变更日志，确认删除操作是误操作还是计划内下线；若为后者，视图应同步 DROP 或改写，而非强行恢复旧表结构
• SQL Server 中若视图引用了已被 DROP 的表，但你还保留着旧备份，别直接还原整库——先从备份里 SELECT * INTO #temp FROM [BackupDB].dbo.Orders 抽结构，再比对字段类型和约束是否兼容当前视图逻辑

依赖检查脚本跑出来一堆红色警告不等于马上要修；真正危险的是那些没人维护、却还在报表任务里被调用的视图——它们往往在凌晨三点崩掉调度，而你根本不知道它连着哪张表。