SQL Server视图周期性查询超时，无代码变更修改视图后临时恢复

问题根因 #

该问题的核心是SQL Server缓存的视图执行计划出现性能退化，ALTER视图操作会强制清空该视图关联的所有缓存执行计划，触发SQL Server重新生成适配当前数据分布的执行计划，因此问题会暂时缓解。
具体触发原因包含以下几点：

• 你的视图使用了UNION而非UNION ALL，两个查询分支的langId分别硬编码为1和2，不存在重复行，UNION额外的全局去重操作会大幅增加查询开销，也会干扰执行计划生成。
• 外部查询传入@lang参数时，会触发参数嗅探问题：SQL Server首次生成执行计划时会基于当时的@lang参数值和数据分布生成最优计划，但由于Product和ProductTranslation表频繁更新，数据分布快速变化，旧的执行计划不再适配新的数据情况，会出现选错连接方式、索引扫描替代索引查找等问题，最终导致查询超时。
• 视图逻辑存在冗余：如果两个分支查询的Product表是同一张表（仅schema不同），完全可以调整视图逻辑避免两次扫描同表，进一步降低执行开销。

解决方案 #

• 优化视图基础逻辑：将UNION替换为UNION ALL，移除多余的去重操作，可直接降低至少30%的视图查询开销。
• 解决参数嗅探问题：
  • 如果该关联查询的调用频率不高，可在查询语句末尾添加OPTION (RECOMPILE)，每次查询强制重新生成适配当前参数的执行计划，重编译开销远低于超时损耗。
  • 由于你的langId仅有1、2两个固定取值，可在查询末尾添加OPTION (OPTIMIZE FOR (@lang = 1, @lang = 2))，让SQL Server生成同时适配两个参数的通用执行计划，避免计划退化。
• 补充索引优化：给ProductTranslation表创建联合索引 (productId, langId) INCLUDE (prName, prDesc)，确保视图左连接操作直接走索引查找，无需回表查询数据。
• 临时应急方案：无需修改视图定义，在业务低峰期定时执行sp_refreshview 'myview'，即可触发执行计划重新生成，对业务的影响远低于ALTER视图操作。

内容的提问来源于stack exchange，提问作者Surensiveaya