SQL Server用sys.sql_expression_dependencies交叉验证视图依赖，MySQL需解析VIEW_DEFINITION正则匹配并核实表存在性，修复前须确认表删除是误操作还是计划下线。
视图引用的基表被删后，视图本身不会报错，但查询时直接失败——必须提前发现并修复，不能等线上报 Invalid object name 才行动。
查哪些视图依赖已删除的基表
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抽结构，再比对字段类型和约束是否兼容当前视图逻辑
依赖检查脚本跑出来一堆红色警告不等于马上要修；真正危险的是那些没人维护、却还在报表任务里被调用的视图——它们往往在凌晨三点崩掉调度，而你根本不知道它连着哪张表。
