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優化本地化地理點的空間索引

回答

相關問題