2017-06-05 7 views
1

特定のバウンディングボックス[ジオコードルックアップ]内のすべてのレコードを検索するクエリがあります。クエリがクラスタ化インデックススキャンを実行する理由

RedGateプロファイラを使用してクエリプランを実行した後、クラスタ化インデックススキャン(下)の中で膨大な時間を費やします。これは私の実行時間が最も遅く、この最終ステップが長くかかるので何か間違っていると思いますか? SO周りを見回したとGoogleが、私は私のインデックス内のテーブルのすべての列を含めることを決定した後

enter image description here

。ここに私が持っているどのようなインデックスがありますか。

  • PKのIDです。
  • [UTC_UPDATED DESC、北、東、南、西] [スキャンを回避しようとする他のすべての列が含ま] [UTC_UPDATED DESC、ソースDESC]の
  • インデックス

クエリのインデックス:

SET ANSI_NULLS ON; SET ANSI_PADDING ON; SET ANSI_WARNINGS ON; SET ARITHABORT OFF; SET CONCAT_NULL_YIELDS_NULL ON; SET NUMERIC_ROUNDABORT OFF; SET QUOTED_IDENTIFIER ON 

(@p__linq__0 datetime2(7),@p__linq__1 float,@p__linq__2 float,@p__linq__3 float,@p__linq__4 float)SELECT 
    [Project1].[ID] AS [ID], 
    [Project1].[CENTER] AS [CENTER], 
    [Project1].[BOUNDS] AS [BOUNDS], 
    [Project1].[UTC_UPDATED] AS [UTC_UPDATED], 
    [Project1].[PLACE_ID] AS [PLACE_ID], 
    [Project1].[FORMATTED_ADDRESS] AS [FORMATTED_ADDRESS], 
    [Project1].[POST_CODE] AS [POST_CODE], 
    [Project1].[SOURCE] AS [SOURCE], 
    [Project1].[North] AS [North], 
    [Project1].[East] AS [East], 
    [Project1].[South] AS [South], 
    [Project1].[West] AS [West] 
    FROM (SELECT 
     [Extent1].[ID] AS [ID], 
     [Extent1].[CENTER] AS [CENTER], 
     [Extent1].[BOUNDS] AS [BOUNDS], 
     [Extent1].[UTC_UPDATED] AS [UTC_UPDATED], 
     [Extent1].[PLACE_ID] AS [PLACE_ID], 
     [Extent1].[FORMATTED_ADDRESS] AS [FORMATTED_ADDRESS], 
     [Extent1].[POST_CODE] AS [POST_CODE], 
     [Extent1].[SOURCE] AS [SOURCE], 
     [Extent1].[North] AS [North], 
     [Extent1].[East] AS [East], 
     [Extent1].[South] AS [South], 
     [Extent1].[West] AS [West] 
     FROM [dbo].[HST_GEOCODE_POINTS] AS [Extent1] 
     WHERE ([Extent1].[UTC_UPDATED] > @p__linq__0) 
      AND ([Extent1].[North] >= @p__linq__1) 
      AND ([Extent1].[East] >= @p__linq__2) 
      AND ([Extent1].[South] <= @p__linq__3) 
      AND ([Extent1].[West] <= @p__linq__4) 
    ) AS [Project1] 
    ORDER BY [Project1].[UTC_UPDATED] DESC, [Project1].[SOURCE] DESC 

メモ境界と中央は地理タイプです。最初はIntersectsを使って正しいジオコーディングされたアドレスを見つけましたが、遅いので、SQLを使ってNESWのバウンディングボックスを見つけ出しました。[単純に2倍です。

+1

SQL Serverの地理サポートをあきらめることを決定する前に、空間インデックスを検討/テストしましたか?非クラスター化インデックスは、ほとんどのシーク述語が不等式であるため、実際には役に立たない。 –

+1

小さく始めると、検索述語(where句)に注目し、内部のProject 1テーブルでフィルタリングしている列の1つを返します。これがクラスタ化されていないインデックスを使用していることを確認します。列を追加すると、オプティマイザが混乱する可能性があります。 – user3112728

+0

インデックスを使用することはできません。索引の先頭の列はUTCであり、照会のUTCの条件はありません。あなたのケースでは、クラスタ化されたインデックススキャンが唯一可能な方法です。 – sepupic

答えて

0

SQL Serverがスキャンまたはシークを行うかどうかは、クエリの選択性によって異なります。あなたの場合、スキャンは単にシークよりも安価です。インデックスがクエリをカバーしているかどうかは問題ではありません。 tipping pointについてお読みください。

+0

ちょうど注記は、当然間違っている可能性が推定値に基づいています。インデックスヒントを追加することで、インデックスの動作の良し悪しを確認することができます。 –

+0

@PawełKucharski 彼は彼の索引にすべての必要な列*を含めたので、あなたは何の話題について話しているのですか? – sepupic

+0

私はシークを意味し、今それを修正しました。申し訳ありません。 – PacoDePaco

関連する問題