ALTER VIEW 不能批量刷新失效视图，因其本质是重建而非刷新；应使用 sp_refreshview 逐个或批量执行，但需注意其不支持 SCHEMABINDING 视图、跨库解析失败、链式失效等限制。
为什么 ALTER VIEW 不能批量刷新失效视图
视图失效（比如底层表字段改名、删列、改类型）后，SQL Server 不会自动更新其元数据定义，查询时才报错：The view or function 'xxx' is not up to date。此时 ALTER VIEW 要求你重写完整定义，根本没法“刷新”——它不是刷新命令，是重建命令。强行执行会失败，因为 SQL Server 拒绝在定义未变更时运行 ALTER VIEW。
用 sp_refreshview 逐个修复最稳妥
SQL Server 提供了专用系统存储过程 sp_refreshview，它会重新解析视图引用的对象，更新 sys.views 中的元数据（如列名、可空性、数据类型），不改动视图逻辑本身。这是唯一被官方支持的“刷新”方式。
批量操作需配合游标或 sys.views 查询生成语句：
DECLARE @sql NVARCHAR(MAX) = ''; SELECT @sql += 'EXEC sp_refreshview ''' + QUOTENAME(s.name) + '.' + QUOTENAME(v.name) + ''';' + CHAR(13) FROM sys.views v JOIN sys.schemas s ON v.schema_id = s.schema_id WHERE v.is_ms_shipped = 0 AND OBJECTPROPERTY(v.object_id, 'IsView') = 1; EXEC sp_executesql @sql; -- 执行后可查：SELECT name, OBJECTPROPERTY(object_id, 'IsSchemaBound') FROM sys.views WHERE OBJECTPROPERTY(object_id, 'IsView') = 1
-
sp_refreshview只处理普通视图，不处理带SCHEMABINDING的视图（后者必须手动ALTER） - 若视图引用了跨库对象，需确保当前上下文能解析三段式名称（如
[OtherDB].dbo.Table），否则刷新失败且无提示 - 执行前建议先用
SELECT name FROM sys.views WHERE OBJECTPROPERTY(object_id, 'IsView') = 1 AND OBJECTPROPERTY(object_id, 'IsSchemaBound') = 0筛出可刷列表
哪些视图 sp_refreshview 刷不了
以下情况调用 sp_refreshview 会静默失败或报错，必须人工干预：
- 视图定义中用了未加引号的保留字作别名（如
SELECT id AS order FROM t），刷新后元数据列名可能异常 - 底层表被重命名但视图里仍用旧名 ——
sp_refreshview不做名称映射，只校验现有对象是否存在 - 视图依赖的函数/视图本身也已失效（链式失效），需从依赖树底部向上逐层刷新
- 使用了
OPENQUERY、链接服务器或 CLR 函数等外部对象，sp_refreshview无法验证其结构
刷新后务必验证列元数据是否同步
刷新成功不代表视图能用。常见坑是：列名没变，但实际类型变了（比如 INT 改成 BIGINT），而 sp_refreshview 不更新视图的列类型缓存，导致后续 SELECT * 或插入到临时表时报类型冲突。
验证方法：
-- 对比视图列定义和实际底层 SELECT 的列 SELECT c.name, c.system_type_id, c.max_length, c.precision, c.scale FROM sys.columns c JOIN sys.views v ON c.object_id = v.object_id WHERE v.name = 'YourViewName'
再手动执行视图的 SELECT TOP 0 *，看实际返回列的类型是否一致。不一致就得重写视图或调整底层对象。
真正麻烦的从来不是“怎么刷”，而是“刷完是不是真好了”——元数据和运行时行为之间那层薄薄的同步，最容易被忽略。
