在SSRS中使用存储过程代替SQL查询时性能下降

为了提高报表的性能（从加载所需的时间来看），我想将源代码从直接查询更改为存储过程，但使用存储过程需要更多的时间

我有一个SQL查询：

SELECT DISTINCT 
    *,
    YEAR(DT_DATE) YEAR1,
    DATENAME(mm, DT_DATE) Month1,
    CAST([Original Service Line TCV] AS float) OSL_TCV,
    CAST([BB12] AS decimal) BB12_new 
FROM
    T_OPTYLINEVIEW_REP 
WHERE 
    [Selling SBU] IN (@selling_SBU) 
    AND [Selling BU] IN (@selling_BU) 
    AND [Selling MU] IN (@selling_MU) 
    AND [Stage] IN (@stage) 
    AND [Account Type] IN (@Account_Type) 
    AND [Business Line] IN (@Business_Line) 
    AND [Business Line Level 1] IN (@Business_Line_Level_1) 
    AND [Business Line Level 2] IN (@Business_Line_Level_2) 
    AND [Offer] IN (@Offer)
    AND [Sector] IN (@Sector) 
    AND [Portfolio] IN (@Portfolio) 
    AND [flag Altran Collaboration] IN (@flag_Altran_Collaboration) 
    AND [Selling Reporting Unit] IN (@Selling_Reporting_Unit) 
    AND CONVERT(VARCHAR, DT_TECH_UPD, 103) = CONVERT( VARCHAR, @ReportAsOn, 103)

我将此查询直接放入SSRS。为此，如果我在报表服务器执行日志中看到检索时间，则大约需要11000毫秒

我将其转换为存储过程以加快处理速度->

[dbo].[OptyLineView_test_proc](    
@selling_SBU nvarchar(max),
@selling_BU nvarchar(max),  
@selling_MU nvarchar(max),  
@stage nvarchar(max),  
@Account_Type nvarchar(max) ,  
@Business_Line nvarchar(max),  
@Business_Line_Level_1 nvarchar(max),  
@Business_Line_Level_2 nvarchar(max),  
@Offer nvarchar(max),  
@Sector nvarchar(max),    
@Portfolio nvarchar(max),  
@flag_Altran_Collaboration nvarchar(max),  
@Selling_Reporting_Unit nvarchar(max),  
@ReportAsOn date)    
as       
select DISTINCT *,    
YEAR(DT_DATE) YEAR1,    
datename(mm,DT_DATE) Month1,    
CAST([Original Service Line TCV] as float)OSL_TCV,    
CAST([BB12] as decimal) BB12_new     
from T_OPTYLINEVIEW_REP     
where [Selling SBU] in (select * from STRING_SPLIT(@selling_SBU, ',')) 
and [Selling BU] in  (select * from STRING_SPLIT(@selling_BU, ','))    
and [Selling MU] in (select * from STRING_SPLIT(@selling_MU,','))     
and [Stage] in (select * from STRING_SPLIT(@stage,','))     
and [Account Type] in (select * from STRING_SPLIT(@Account_Type,','))     
and [Business Line] in (select * from STRING_SPLIT(@Business_Line,','))     
and [Business Line Level 1] in (select * from STRING_SPLIT(@Business_Line_Level_1,','))    
and [Business Line Level 2] in (select * from STRING_SPLIT(@Business_Line_Level_2,','))    
AND [Offer] in (select * from STRING_SPLIT(@Offer,','))   
AND [Sector] in (select * from STRING_SPLIT(@Sector,','))     
AND [Portfolio] in (select * from STRING_SPLIT(@Portfolio,','))     
AND [flag Altran Collaboration] in (select * from STRING_SPLIT(@flag_Altran_Collaboration,','))    
AND [Selling Reporting Unit] in (select * from STRING_SPLIT(@Selling_Reporting_Unit,','))    
AND CONVERT(VARCHAR,DT_TECH_UPD , 103) = CONVERT(VARCHAR,@ReportAsOn , 103)

当我在SSRS中使用此过程时，数据检索时间约为100000 ms

---

为什么在存储过程中它会增加？？？

简单地将查询封装在存储过程中并不能提高性能。在这里，您似乎做了其他更改（例如

STRING\u SPLIT

）。要做的一件事是确保列数据类型与比较列的数据类型匹配<由于您的

nvarchar（MAX）

参数，code>STRING\u SPLIT将返回

nvarchar

，因此索引可能无法有效使用。此查询看起来异常繁重。SELECT*通常是一种不好的做法，除非您确实需要每一列，在这种情况下，您应该指定列名。您的表是否有主键，甚至索引？这两个问题将帮助服务器找出如何回答这个问题。嗯，让我们看看：存储过程只会对参数嗅探产生影响，这在这里可能不相关。现在将这些列表声明为

nvarchar（max）

并将它们拆分，使用表参数或临时表（出于数据类型原因和查询计划）要好得多。我只能猜测原始查询在做什么，但是（@Selling_SBU）中的

[Selling SBU]永远不会与CSV列表一起工作
CONVERT（VARCHAR，DT_TECH_UPD，103）
不是比较日期的方法，使用
CONVERT（date，DT_TECH_UPD）
或更好的方法，与
=和….进行适当的半开范围比较。。。。而且
SELECT*
没有帮助，当然
DISTINCT
会给查询计划增加更多不必要的压力。如果您希望在此处获得真正的SQL性能帮助，则必须提供表和索引定义，并通过@Charlieface共享查询计划。原始查询（和SP）将从reporting services调用（@Selling_SBU）中的[Selling SBU]
是这样做的正确语法-我认为会发生一些字符串替换。有趣的是，下面是如何使用。