9

100MM を超えるレコードを含むテーブルがあります。テーブルには、クラスター化インデックスと非クラスター化インデックスがあります。

テーブルで T-SQL を使用して基本的なカウントを実行でき、実行に 1 秒かかります。同じ正確な数のクエリをストアド プロシージャ内に配置すると、実行に 12 秒かかります。

標準クエリとストアド プロシージャの両方の実行プランを確認しましたが、どちらも非クラスター化インデックスを使用しています。

ストアド プロシージャが標準のクエリに比べて遅い理由がわかりません。

このような状況でのインデックスの再作成についていくつか読んだことがありますが、なぜそれを行う必要があるのか​​わかりません。また、インデックスの再作成には数時間かかるため、確実に機能するようにしたいと考えています。

これに関するヘルプは素晴らしいでしょう。

ありがとう

アップデート

ストアド プロシージャは次のとおりです。

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

ALTER PROCEDURE quickCount 

@sYID INT,
@eYID INT

AS
BEGIN

SET NOCOUNT ON;


    SELECT COUNT(leadID)
    FROM dbo.leads
    WHERE yearID >= @sYID
    AND yearID <= @eYID

END
GO

そして、これが標準的なクエリです:

SELECT COUNT(leadID)
FROM leads
WHERE yearID >= 0
AND yearID <= 99

パラメータなしで実行しようとしたところ、SP の実行速度が大幅に向上しました (1 秒)。だから私はそれがパラメータと関係があると仮定しています。

4

5 に答える 5

16

渡された変数のローカル コピーを使用するように SP を変更してみてください。

何かのようなもの

ALTER PROCEDURE quickCount  

@sYID INT, 
@eYID INT 

AS 
BEGIN 

SET NOCOUNT ON; 
    DECLARE @Local_sYID INT, 
            @Local_eYID INT 
    SELECT  @Local_sYID = @sYID INT, 
            @Local_eYID = @eYID INT

    SELECT COUNT(leadID) 
    FROM dbo.leads 
    WHERE yearID >= @Local_sYID 
    AND yearID <= @Local_eYID 

END

その前に、パラメーター スニッフィングが原因で、SP の実行速度が大幅に低下する可能性があることを発見しましたが、変数のコピーを使用すると、パフォーマンスが回復します。

パラメータスニッフィングとは？

SQL Server : パラメータ スニッフィング

于 2012-10-22T05:02:54.270 に答える
4

すでに述べたように、これはパラメーター スニッフィングの問題である可能性があります。次の行を含めてみてください。

OPTION (RECOMPILE)

SQL クエリの最後に。

ここに、パラメーター スニッフィングとは何かを説明する記事があります。

于 2014-01-22T16:44:50.353 に答える
1

あなたはいつでもそれを動的SQLとして実行しようとすることができます：

ALTER PROCEDURE quickCount  

@sYID INT, 
@eYID INT 

AS 
BEGIN 
    SET NOCOUNT ON;

    DECLARE @SQL VARCHAR(max)

    SELECT @SQL = '
    SELECT COUNT(leadID) 
    FROM dbo.leads 
    WHERE yearID >= '+CONVERT(VARCHAR(20),@sYID)+'
    AND yearID <=   '+CONVERT(VARCHAR(20),@eYID)

    EXEC (@SQL)
END
于 2012-10-22T06:57:30.797 に答える
0

ストアドプロシージャを初めて実行するとき、SQL Serverはストアドプロシージャをコンパイルする必要がありますが、これには時間がかかる場合があります。@Astanderは、パラメータスニッフィングについて言及しました。これは有効なポイントであり、結果を歪める可能性があります。

考慮すべき他のいくつかの要因は次のとおりです（実際には症状を説明するべきではありませんが）：

  • たとえば、テーブル名の後にロックレベルを強制WITH (NOLOCK)すると、問題が解決する可能性があります（ただし、これを行うと不正確な結果が得られる可能性があることに注意してください）。
  • テーブルの統計を更新するか、インデックスを最適化する必要がある場合があります
于 2012-10-22T20:25:52.377 に答える