【问题标题】:SQL Server 2008 Spatial Query performanceSQL Server 2008 空间查询性能
【发布时间】:2013-02-08 00:31:43
【问题描述】:

我有一个应用程序,用户在我们的数据库中存储他们的通勤路线。

路线存储为折线(线串)。 数据库还存储事故、交通事故之类的东西。 我们需要定期查询一条路线,看看在路线的 1k 半径范围内是否有任何事件发生。

查询的连接结构如下:

    Route r left outer join Incident i on
    r.PolyLine.STDistance(i.Location) < 1000

现在我也尝试了这样的事情:

Route r left outer join Incident i on   
r.PolyLine.STBuffer(1000).STIntersects(i.Location) = 1

到目前为止,我们为提高速度所做的尝试有:

  1. 减少沿线串的点数
  2. 添加空间索引(虽然我不知道如何调整)

1) 上述方法有效,但还不够好,这让我相信该事件正在与路线上的每个点进行比较,这似乎真的效率低下。

我们正在考虑将长纬度作为几何与地理的对比,因此我们可以访问边界框并获得 STContains。

还考虑在检查事件之前在折线上调用 reduce。

【问题讨论】:

  • 您是否可以在插入路线时考虑为特定路线存储多点,或者是在您存储路线并仅在之后请求事件的地方?

标签: sql-server-2008 spatial-index spatial-query sqlgeography


【解决方案1】:

我会建议几何存储。在这种情况下,去地理的好处似乎并没有超过成本。

空间索引非常重要。通过使用适当调整的空间索引,我使用空间查询的一个过程从约 15 分钟到约 1 分钟。但是,我还没有找到关于自动为它们获取最佳设置的好方法的文档。我已经回答了similar question about spatial index tuning。我在那里提供的存储过程需要一段时间来处理每个数据集,但可以在您做其他工作时在后台运行。

就您的查询而言,我设置了一个不同的查询并将其性能与您在上面提供的两个进行比较。通过将路线缓冲区放入几何变量并在空间比较中使用该变量,性能似乎有所提高。我这样做的原因是它只需要创建一次缓冲区(或评估距离),而不是为其比较的每一行创建一次。你可以试试这个,看看你会得到什么结果。

DECLARE @routeBuff geometry
SET @routeBuff = (SELECT r.PolyLine.STBuffer(1000) FROM route r WHERE recordID = 2778) --how ever you select the particular route

SELECT
    *
FROM
    incident i
WHERE
    i.location.STIntersects(@routeBuff) = 1

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-08-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-05-14
    相关资源
    最近更新 更多