c# - 从 DotNet 执行存储过程需要很长时间，但在 SSMS 中它是立即的

Question

我在 SQL Server 2000 上有一个带 3 个参数的存储过程。当我使用 SqlCommand.ExecuteReader () 从 DotNet 调用存储过程时，大约需要 28 秒。

当我直接在 SSMS 中运行相同的查询时，它会立即返回。

当我从存储过程中取出查询并使用 DotNet 直接运行它时，它也会立即返回。

这些是 SQL Profiler session 的结果

SP 内部点网

• 持续时间:28030
• 阅读:2663365
• 写入:0

SP 内部 SSMS

• 时长:450
• 阅读:23535
• 写作:65

直接在 Dot Net 中查询

• 持续时间:360
• 阅读:24865
• 写:57

以下几点对我来说很突出:

• SSMS 和 Dot Net 中的直接查询的统计数据非常相似
• Dot Net SP 进行大量读取但不进行写入
• 另外两个很少读取，但有一些写入

如有任何帮助，我们将不胜感激。

这是 SP 的一个稍微模糊的版本:

我怀疑这是一个查询计划问题，因为即使我从 DotNet 重复运行它，我总是得到相同的结果。

这是 SP 的一个版本，由于 IP 问题而略有改动。我希望它仍然有意义:

SELECT 
t1.pkiOrderID,
t1.fkiBasketId,
t1.sOriginBasketCode,
t1.dtDateCreated,
t1.sOrderCode,
t1.fkiUserCde,
t1.fkiOrgCde,
t1.sApprovalPerson,
t1.dtDateApproved,
t1.sRequestNo,
t1.dtRequiredDate,
t1.Requestor,
t1.OnBehalfOf,
t1.OrderDesc,
t1.OrderTypeId,
t1.fkiAgentID,
t1.fkiAgentRegionID,
stat.iStatus,
count(oi.pkiOrderItemId) as OrderItems,
count(wf.fkiOrderId) as WorkflowCount,
t1.Currency_Id,
t1.ExchangeRate,
t1.ref_odr_idn,
t2.sOrderCode as ref_odr_cde,
t1.ref_rfq_nbr,
t1.ref_rfs_nbr,
t1.ref_doc_nbr,
t1.ref_rsn,
t1.ref_forip_cde,
t1.ref_fa_nbr,
t1.odr_sub_typ
FROM    tbl1 t1 INNER JOIN 
tbl1Status stat ON
t1.pkiOrderID = stat.fkiOrderID AND
stat.dtDateStatusChanged = (SELECT MAX(stat2.dtDateStatusChanged) 
FROM tbl1Status stat2
WHERE stat2.fkiOrderId = t1.pkiOrderID) LEFT OUTER JOIN 
tbl1Item oi ON
t1.pkiOrderID = oi.fkiOrderId LEFT OUTER JOIN
tbl1Workflows wf ON
t1.pkiOrderID = wf.fkiOrderId LEFT OUTER JOIN 
tbl1 t2 ON 
t1.ref_odr_idn = t2.pkiOrderID
WHERE (t1.fkiUserCde = 'x'
or t1.fkiUserCde in (select fkiUserCde from tbl1 where fkiOrgCde in 
(select sys_org_cde from tbl3 t3 where t3.sys_lnk_org_cde = '123')))
AND ((t1.fkiOrgCde = '123'
and ('123' not in (select sys_org_cde from tbl3 t3) 
or (t1.OrderTypeID <     1 or stat.iStatus IN (2,3,4,5,6,7))))
OR (t1.fkiOrgCde in (select sys_org_cde from tbl3 t3 where     t3.sys_lnk_org_cde = '123')
and t1.OrderTypeID = 1 
and stat.iStatus NOT IN (2,3,4,5,6,7)))           
          AND   t1.OrderTypeID = 2

        GROUP BY
            t1.pkiOrderID,
            t1.fkiBasketId,
            t1.sOriginBasketCode,
            t1.dtDateCreated,
            t1.sOrderCode,
            t1.fkiUserCde,
            t1.fkiOrgCde,
            t1.sApprovalPerson,
            t1.dtDateApproved,
            t1.sRequestNo,
            t1.dtRequiredDate,
            t1.Requestor,
            t1.OnBehalfOf,
            t1.OrderDesc,
            t1.OrderTypeId,
            t1.fkiAgentID,
            t1.fkiAgentRegionID,
            stat.iStatus,
            t1.Currency_Id,
            t1.ExchangeRate,
            t1.ref_odr_idn,
            t2.sOrderCode,
            t1.ref_rfq_nbr,
            t1.ref_rfs_nbr,
            t1.ref_doc_nbr,
            t1.ref_rsn,
            t1.ref_forip_cde,
            t1.ref_fa_nbr,
            t1.odr_sub_typ
        ORDER BY t1.dtDateCreated DESC

抱歉格式化。我努力让它在论坛上完全可读。

Answer 1

因为我的评论似乎提供了正确的答案，所以我决定本着 stackoverflow 的精神将它变成一个完整的答案供后代使用。

您的问题似乎是由 SQL Server 的 Parameter Sniffing 引起的. 为防止出现这种情况，只需将传入的参数值分配给在 SP 顶部声明的其他变量即可。

See this nice Article about it

例子:

CREATE PROCEDURE dbo.MyProcedure
(
    @Param1 INT
)
AS

declare @MyParam1 INT
set @MyParam1 = @Param1

SELECT * FROM dbo.MyTable WHERE ColumnName = @MyParam1 

GO

我从 eggheadcafe.com 复制了这些信息.

编辑:根据 Johann Strydom 的评论，这是另一种选择: Optimize Parameter Driven Queries with SQL Server OPTIMIZE FOR Hint .