sp_refreshview 是首选方案，因其专为视图设计，语义清晰、调用安全，能准确更新元数据且不破坏权限、依赖等；而 sp_refreshsqlmodule 虽可替代但约束多、不支持架构绑定视图，且语义模糊。
视图元数据过期不会报错，但查询结果会漏字段、类型错、甚至 NULL 代替新列 —— 必须手动刷新，SQL Server 不会自动同步。
为什么 sp_refreshview 是首选方案
当基础表（如 Person.Person）新增列、修改列宽或重命名后，视图的列定义仍停留在创建时快照状态。系统视图 sys.columns 中对应视图的记录不会自动更新，导致 SELECT * 或显式引用新列时报错或返回空值。
-
sp_refreshview专为视图设计，只接受一个参数：@viewname，语义清晰、调用安全 - 它重新解析视图定义中的
SELECT语句，从当前基础对象获取最新列结构，并更新sys.columns和sys.views中的元数据 - 不改变权限、依赖关系、扩展属性或 SET 选项，也不会重建视图对象本身
- 执行失败时返回非零错误码，但不会回滚事务 —— 需检查
@@ERROR或捕获输出
sp_refreshsqlmodule 能替代 sp_refreshview 吗
可以，但没必要无脑替换。两者刷新效果一致，但 sp_refreshsqlmodule 是通用型存储过程，覆盖范围更广（存储过程、函数、触发器、视图），也因此引入额外约束：
- 必须显式指定
@namespace参数（默认为OBJECT），视图属于该类，可省略；但 DDL 触发器必须传DATABASE_DDL_TRIGGER等值 - 不支持架构绑定（
SCHEMABINDING）的视图 —— 若视图带WITH SCHEMABINDING，调用sp_refreshsqlmodule会报错，而sp_refreshview仍可成功 - 对多部分名称（如
[Sales].[vIndividualCustomer]）支持相同，但需用单引号包裹完整名称 - 性能差异可忽略，但语义明确性差：看到
sp_refreshsqlmodule无法立刻判断目标是视图还是其他模块
批量刷新所有视图的可靠写法
不要依赖游标拼接字符串再 EXEC(@sql) —— 容易因视图名含特殊字符（如空格、短横线）或跨架构失败。推荐使用 sys.views + QUOTENAME 构建安全脚本：
DECLARE @sql NVARCHAR(MAX) = N''; SELECT @sql += N'EXEC sp_refreshview ' + QUOTENAME(QUOTENAME(s.name) + '.' + QUOTENAME(v.name)) + N';' + CHAR(13) FROM sys.views v INNER JOIN sys.schemas s ON v.schema_id = s.schema_id WHERE v.is_ms_shipped = 0; <p>-- 打印预览（上线前务必先看） PRINT @sql;</p><p>-- 确认无误后执行 -- EXEC sp_executesql @sql;</p>
- 过滤掉
is_ms_shipped = 1的系统视图，避免干扰 -
QUOTENAME套两层：外层包完整三段名（[schema].[view]），内层包 schema 和 view 名，防注入和语法错误 - 生产环境务必先
PRINT出脚本，人工抽检 2–3 条是否符合预期，再取消注释执行 - 若某视图刷新失败（如依赖对象已删），整个批处理会中断 —— 需配合
TRY...CATCH单独捕获每个视图
容易被忽略的刷新时机和边界情况
刷新不是“改完表就立刻跑一遍”那么简单。几个关键点常被跳过：
- 表结构变更后，如果视图里没引用变动的列（比如只选了
FirstName, LastName，而你只改了Email列），sp_refreshview仍有必要执行 —— 因为统计信息、执行计划缓存可能残留旧结构引用 - 使用
SELECT *的视图最危险：新增列后不刷新，查询完全看不到该列；但即使没用*，只要列类型变（如VARCHAR(50)→VARCHAR(100)），元数据不刷新会导致LEN()或截断行为异常 - 在 SSDT 或 SQL Server Data Tools 中发布变更时，勾选 “Drop objects in target not in source” 可能意外删掉视图再重建 —— 这比刷新更彻底，但会丢失权限和依赖链，慎用
- 复制环境（如事务复制）中，如果发布数据库刷新了视图，订阅端不会自动同步元数据 —— 必须在订阅端单独执行刷新，否则查询结果仍滞后
