这个问题我碰到过好多次了——单独跑都快，一连接就暴慢，核心往往是查询优化器没有把两个查询的逻辑高效合并，或者连接时的数据集太大导致开销飙升。先给你明确回答关键问题，再讲其他优化思路：

一、创建索引视图能否让查询在合理时间完成？ #

大概率可以，但要注意索引视图的前提条件：

• 视图必须加上WITH SCHEMABINDING，绑定到基表的架构上，不能随意修改基表结构；
• 视图里不能包含不确定函数（比如GETDATE()）、子查询、TOP 100 PERCENT这类会导致结果不确定的逻辑；
• 如果有聚合函数，必须包含COUNT_BIG(*)来满足索引视图的统计要求。

一旦创建了索引视图，数据库会把视图的结果物化存储（相当于提前计算好并存在磁盘上），连接时直接用这个预计算的数据集，不用每次重新执行视图的逻辑。这时候连接的开销会大幅降低，总耗时大概率能回到两个查询单独执行时间的总和附近（甚至更低，因为索引视图本身的索引可以优化连接步骤）。

二、除了创建索引视图，还有这些优化方法 #

1. 先看执行计划，精准定位瓶颈 #

别盲目优化，先跑一下查询的执行计划（比如SQL Server里按Ctrl+L），重点看这几个点：

• 是不是视图的逻辑被重复执行了？比如优化器没有把视图和主查询合并，导致视图被调用N次；
• 连接步骤用的是什么方式？如果数据量很大却用了嵌套循环连接，换成哈希连接可能会快很多；
• 有没有出现全表扫描或者索引扫描？这往往是连接字段没索引，或者统计信息过时导致的。

2. 给视图提前过滤数据 #

你的视图单独跑1分钟，但如果返回的数据集很大，和主查询连接时的匹配开销会爆炸。可以：

• 如果视图是专用的，直接在视图里加上WHERE Year = @year这类过滤条件，缩小返回的数据量；
• 如果视图是通用的不能改，就在连接时手动过滤：

  -- 原来的连接可能是 JOIN your_view v ON ...
  -- 改成这样，提前过滤视图数据
  JOIN (SELECT * FROM your_view WHERE Year = @year) v ON ...
  

  这样视图返回的行数少了，连接自然更快。

3. 优化连接字段的索引和数据类型 #

• 检查主查询（包括CTE里）和视图的连接字段有没有建索引？比如主查询里的M.Brand如果是连接字段，给它建个非聚集索引能大幅提升匹配速度；
• 确保连接字段的数据类型完全一致：比如一个是VARCHAR(50)，另一个是NVARCHAR(50)，会触发隐式转换，导致索引失效，连接变成全表扫描，这绝对是性能杀手。

4. 用临时表替代CTE（如果CTE数据量大） #

你的主查询用了CTE，有时候优化器会把CTE当成无索引的临时数据集，连接时效率很低。可以把CTE的结果插入临时表并加索引：

DECLARE @year INT=2017;
-- 把CTE的结果存入临时表
SELECT M.Brand, M.SubBrand, M.Detail, S.Unit...
INTO #tempData
FROM ... -- 原来的data CTE的逻辑
-- 给连接字段建索引
CREATE NONCLUSTERED INDEX IX_tempData_JoinFields ON #tempData(Brand, SubBrand);
-- 用临时表和视图连接
SELECT ...
FROM #tempData d JOIN your_view v ON d.Brand = v.Brand AND d.SubBrand = v.SubBrand ...

临时表的索引能让连接步骤的匹配效率提升几个量级。

5. 更新统计信息 #

如果数据库的统计信息过时了，优化器会生成糟糕的执行计划（比如错误判断数据量大小，选了低效的连接方式）。跑一下这些语句更新统计信息：

-- 更新主查询涉及基表的统计信息
UPDATE STATISTICS MainTable;
-- 更新视图基表的统计信息
UPDATE STATISTICS ViewBaseTable1;
UPDATE STATISTICS ViewBaseTable2;

更新后优化器能准确判断数据分布，选择更优的执行策略。

6. 拆分复杂查询 #

如果连接后的查询逻辑太复杂（比如有多层嵌套、聚合），可以拆成多步：

1. 先把主查询的结果存入临时表A，加索引；
2. 把视图的筛选结果存入临时表B，加索引；
3. 最后连接临时表A和B得到结果。
   这样每一步的开销都可控，而且临时表的索引能最大化连接效率。

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