優化邊界框查詢

我有一個GeocodedPoints表。我正在優化的這個查詢嘗試爲經緯度位置提取匹配點。不幸的是它太慢了！優化邊界框查詢

該表基本上是邊界框和相應地址的列表。它還包含精確邊界框的DBGeography，但是，鑑於SQL在這種情況下的速度有多慢，我將它轉化爲.NET land並在那裏查詢DBGeography。

我的查詢然後基本上看看是否在邊界框內[由NESW指定]並返回結果。

在我看來，這應該是非常快，但唉，它並不像我想的那樣快。

我對邊界一個無唯一，非聚集索引和像這樣

注意，因爲我們只返回已修改在過去2結果UTC需要對UTC周。

我已經通過SQL事件探查器工具來運行這一點，這裏的一些信息：

50萬行該表
時間從每次通話
250-350ms範圍從5-20k

最後這裏是我的查詢使用

exec sp_executesql N'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',N'@p__linq__0 datetime2(7),@p__linq__1 float,@p__linq__2 float,@p__linq__3 float,@p__linq__4 float',@p__linq__0='2017-05-16 11:12:12.4425257',@p__linq__1=53.016466402998645,@p__linq__2=-1.715320912729779,@p__linq__3=53.016466402998645,@p__linq__4=-1.715320912729779

注意我的UTC當前是第一個在這個查詢中，但最後在索引。具有諷刺意味的是，這似乎使我的查詢速度更快，但每次調用都能達到20k次。

來源

2017-05-30 Chris

@GordonLinoff我不確定你的意思？我已經在桌面上有一個DBGeography，但不能用它查詢太慢。 – Chris

注意從SQL Sentry Plan Explorer（一個免費工具）添加執行計劃？這會有很大的幫助。 –

通常在兩週內更新了多少行。如果沒有那麼多，它可能會*更有效率的日期列在索引中第一個... – user1429080

1）使用geography代替DBGeography來存儲數據：上geography柱 https://docs.microsoft.com/en-us/sql/relational-databases/spatial/spatial-indexes-overview

3）尋求行的行，需要使用your_geography.STIntersects(other_geography)功能或類似 https://docs.microsoft.com/en-us/sql/t-sql/spatial-geography/spatial-types-geography

2）創建一個空間索引

不幸的是你不能在你的空間索引的另一列（例如UTC_UPDATED）。

p.s.你也可以試試geometry類型

來源

2017-05-30 13:39:18

嗨，謝謝你的回答。我已經有一個地理類型的列，並有一個索引，但它比我目前的方法慢得多。我現在的方法實際上在執行時間上實際上快了50倍，讀取的行少了約15倍 – Chris

快50倍意味着使用'geography'列查詢執行300ms * 50 =〜15秒？你確定空間索引已被使用？有多少行按座標過濾，有多少行按日期過濾？ –

當我寫下我的統計數據時，使用地理位置的查詢耗時1650毫秒，打了319,450次讀取。通過上面的查詢，它達到了21,195次讀取並花費了31ms。在系統運行了幾天之後，我看到它減緩了一下，因此想知道我能做些什麼。我在網上看到的每一個資源都表明，地理本質上是緩慢的？ – Chris

優化邊界框查詢

回答

相關問題