2012-03-21 23 views
0

次のクエリは、約70000レコードを取得するのに時間がかかります。私は実行時間が検索されたレコードの数に比例することに気づいた。実行時間が検索されたレコードの数に比例しないように、このクエリを最適化する必要があります。何か案が?SUMとCOUNT関数を持つSQLクエリを最適化する

;WITH TT AS (
     SELECT TaskParts.[TaskPartID], 
     PartCost, 
     LabourCost, 
     VendorPaidPartAmount, 
     VendorPaidLabourAmount, 
     ROW_NUMBER() OVER (ORDER BY [Employees].[EmpCode] asc) AS RowNum 
     FROM [TaskParts],[Tasks],[WorkOrders], [Employees], [Status],[Models] 
     ,[SubAccounts]WHERE 1=1 AND (TaskParts.TaskLineID = Tasks.TaskLineID) 
AND (Tasks.WorkOrderID = [WorkOrders].WorkOrderID) 
AND (Tasks.EmpID = [Employees].EmpID) 
AND (TaskParts.StatusID = [Status].StatusID) 
And (Models.ModelID = Tasks.FailedModelID) 
And (SubAccounts.SubAccountID = Tasks.SubAccountID)AND (SubAccounts.GLAccountID = 5)) 
SELECT --* 
    COUNT(0)--, 
    SUM(ISNULL(PartCost,0)), 
    SUM(ISNULL(LabourCost,0)), 
    SUM(ISNULL(VendorPaidPartAmount,0)), 
    SUM(ISNULL(VendorPaidLabourAmount,0)) 
    FROM TT 
+3

「TT」からの出力のみを選択しています。 'TD0'、' TD1'、 'TP1'は冗長であるので、それらを削除してください。 –

+0

これらのテーブルはこの問題の原因ではありません。開始からそれらを省略したはずであることがわかっていれば、それはCOUNTとSUM – mohammedn

+0

のクエリです。多くの人々は単に移動します。あなたは長い質問を投稿することによって自分自身に不利益を与えています。 –

答えて

2

リーフェンが指摘したように、彼らは冗長であるとして、あなたはTD0TD1TP1を削除することができます。

row_numberカラムは使用されておらず、ウィンドウ関数は比較的高価なので削除することもできます。

CTEが使用されていない場合は、一部のテーブルをCTEから削除することもできます。ただし、選択された各列に表名が含まれていないため、使用されていない表を特定することはできません。

これ以外にも、RDBMSは結果を計算するために返された各行を読み込む必要があるため、クエリの応答は常に返される行の数に比例します。

+0

+1より完全な分析のために。 –

+0

ありがとう、マーク。この遅延の原因となる結合があると思われます.Modelsテーブルとの結合です。ただし、この表には丸ごと7000個のレコードしか含まれていませんが、まだそれほど時間がかかりません。 – mohammedn

+1

@mohammedn - 実行計画を投稿できますか? –

0

外部キーごとにサポートインデックスがあることを確認してください。ほとんどの場合、このケースでは問題はありませんが、MS SQL最適化は内部結合でうまく機能します。 また、合計が必要な場合はRowNumが必要な理由はありません。