优化边界框查询

我有一个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

优化边界框查询

回答

相关问题