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

我有〜400k兴趣点存储在GEOGRAPHY空间sql。SQL优化本地化地理点的空间索引

我会查询这些点与PointOfInterest.STDistance（@CentralPoint）< @Radius到找到PointOfInterest的发送到查询@CentralPoint的一定半径内。

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

LEVEL_1 =中，LEVEL_2 =中，LEVEL_3 =中，LEVEL_4 = MEDIUM

但是我的情况是这样的，我会只有内theUK的兴趣点。尽管令人敬畏，但我们只占用了terra firma的相对规格，所以我想知道是否有更好的网格模式用于这种情况的空间索引。

作为地理基础我不能使用可爱的几何边界框。我也是使用SQL Azure的这似乎不具有空间帮助存储的特效:(

来源

2014-04-15 BritishDeveloper

一如以往与空间索引，你最终会发现，您的数据集测试各种网格设置可以产生不同的结果也就是说，我发现所有级别的Low设置都是低的，或者Medium，Low，Low，Low会产生很好的结果，因为它们的简单性使得它们的分数很高。

但是，为了充分利用索引，并且检查一个十字路口，再次，我发现它通常会产生一贯较低的结果时间，但是可以在您的数据上进行测试

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

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

尝试远离切换到几何图形的冲动，尽管它会产生更快的查询，但由于使用平面模型，它有更多机会产生“不正确”的结果。这就是说，如果搜索距离足够小，在大多数情况下，差异将不会显着。

来源

2014-04-15 12:45:10

谢谢！请你简单地解释一下你对低级网格的建议的优点，因为我认为在阅读它们时，更精确的“高”听起来是最好的 – BritishDeveloper

@BritishDeveloper，使用低级网格保持索引相对较轻和快速 - LLLL其中最多只有65536个4级单元。测试多组信息（包括英国数据）通常比其他组合（我全部试过）产生的效果好于或等于性能。然而，在处理多边形时，需要更高的层次来更好地处理复杂性，以及对每个对象的单元格值进行试验。有些情况下，我发现MLLL或HLLL更好，所以我也建议尝试它们，但有400k行，我们正在说10秒的MS顶部 –

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

回答

相关问题