SQL优化本地化地理点的空间索引

时间:2014-04-15 09:44:10

标签: sql optimization indexing spatial spatial-index

〜400k兴趣点存储在 GEOGRAPHY 空间sql中。

我将使用PointOfInterest.STDistance(@CentralPoint)<来查询这些点。 @Radius 在发送到查询的@CentralPoint的某个半径内找到PointOfInterest。

我已经阅读了一些关于网格分层的内容,并希望有人知道他们的东西,以推荐最明智的网格模式。默认值为

  

LEVEL_1 = MEDIUM,LEVEL_2 = MEDIUM,LEVEL_3 = MEDIUM,LEVEL_4 =   MEDIUM

但我的情况是这样的,我只会在英国境内有兴趣点。虽然很棒,但我们只考虑了一个相对的terra firma规范,所以我想知道在这种情况下是否有更好的网格模式用于空间索引。

基于地理位置我不能使用可爱的几何边界框。我也在使用SQL Azure,它似乎没有空间帮助存储过程:(

1 个答案:

答案 0 :(得分:2)

与空间索引一样,您最终会发现在数据集上测试各种网格设置可能会产生与其他网格设置不同的结果。也就是说,我发现在所有级别设置为低,或者中,低,低,低会因为它们的简单性而产生很好的结果。

为了充分利用索引,可以考虑选择缓冲点并检查交叉点。同样,我发现它通常会产生更好的始终如一的低结果时间,但会对您的数据进行测试。

DECLARE @point GEOGRAPHY = GEOGRAPHY::STPointFromText('POINT(<coords>)', 4326);
DECLARE @radius INT = 1000;

SELECT
*
FROM <table>
WHERE <GeographyColumn>.STIntersects(@point.STBuffer(@radius)) = 1;

尽量避免切换到Geometry的冲动,因为虽然它会产生更快的查询速度,但由于使用平面模型,它有更多机会产生“不正确”的结果。也就是说,如果搜索距离足够小,在大多数情况下差异都不会明显。