0

proc が呼び出された場合、SQL プロファイラーに以下のレコードが表示されます。

CPU - 78、読み取り - 3508、書き込み - 0、期間 - 81

上記のデータは、私の Web サイトでの 70 人の同時ヒットに対して問題ありません。私の proc は、ユーザーがアクセスしているすべてのページで呼び出されます。私のサーバーのパフォーマンス モニターは、SQL proc 呼び出しを有効にすると、匿名ユーザーのヒットが増加し続けることを示しています。

何をどこで見ることができるかを提案してください!!、私のprocクエリを以下に示します。

ALTER PROCEDURE [dbo].[GETDataFromLinkInfo] 
-- Add the parameters for the stored procedure here 
(@PageID INT) 
AS 
  BEGIN 
      -- SET NOCOUNT ON added to prevent extra result sets from 
      -- interfering with SELECT statements. 
      SET NOCOUNT ON; 

      -- Insert statements for procedure here 
      SELECT DISTINCT [PUBLICATION_ID] AS n, 
                      [URL]            AS u 
      FROM   [LINK_INFO] WITH(NOLOCK) 
      WHERE  Page_ID = @PageID 
             AND Component_Template_Priority > 0 
             AND PUBLICATION_ID NOT IN( 232, 481 ) 
      ORDER  BY URL 
      FOR XML RAW ('p'), ROOT ('ps'); 

      RETURN 
  END
4

2 に答える 2

1

Execute the proc 1000 times and measure how long it took. This is the most important metric to judge performance (time elapsed). Don't measure reads and writes.

Regarding my advice not to look at reads/writes: Reads, however, can either be cached or non-cached which is a huge difference. I always look at the execution plan to see why a query is behaving the way it is and what do to. The read/write metrics neither tell you if you need to act nor what do to.

于 2012-04-29T11:22:40.177 に答える
0

Phil が示唆しているように、データベース エンジン チューニング アドバイザーを使用してクエリを分析するのがおそらく最善の策です。ここで正確な回答を得るには、さらに多くの情報を提供する必要があります。人々は 1 つ以上のインデックスを提案するかもしれませんが、インデックスの有効性はその中の列の選択性に依存します。役に立たないインデックスを追加すると、実際には他の方法でパフォーマンスに悪影響を与える可能性があります。

于 2012-04-29T17:12:36.587 に答える