Azure的SQL Server空間指數誤差不能創建...因爲列計算

Question

[更新]我想下面的索引定義並收到以下錯誤消息：

Cannot create primary xml, selective xml or spatial index 'SI_Property' on table 'BTSOne.dbo.Properties', column 'Point', because the column is computed. 

這是有道理的，但現在我回來了到一個方。

我試圖這樣做的原因是什麼？由於查詢超時。我爲所有其他查詢設置了索引，除了空間查詢之外，它們是執行查詢的主要類型。

我有點困惑在哪些列上創建空間索引。我擔心，因爲有些記錄缺少影響點列（索引列）的經度和緯度值（默認爲零）。起初我以爲我可以在點欄上創建索引，但閱讀關於此問題的文章表明我使用了多列。我讀得越多，我就變得越迷惑。此外，還有正確設置網格的問題。經驗法則似乎將它們設置爲高。

這些都是相關的表列：

[Latitude] [float] NULL CONSTRAINT [DF_Properties_Latitude] DEFAULT ((0)), 
    [Longitude] [float] NULL CONSTRAINT [DF_Properties_Longitude] DEFAULT ((0)), 
[Point] AS ([geography]::Point([Latitude],[Longitude],[SRID])), 
[SRID] [int] NULL CONSTRAINT [DF_Properties_SRID] DEFAULT ((4326)), 

這是存儲過程的相關部分：

DECLARE @SearchPoint as geography, 
    @Region nvarchar(80) 

    SET @SearchPoint = geography::Point(@Latitude, @Longitude, 4326) 

    DECLARE @tempTable dbo.WorkingProperties 

    SELECT [PropertyId] AS "Id", ISNULL([InnCode],'NA') AS "InnCode", [UseName] AS "OfficeName", [Addr1] As "Address", [City] 
    , [Zip] AS "PostalCode", [CountryCode], [Brand], [BrandCode] ,[Latitude], [Longitude], 
    ([Point].STDistance(@SearchPoint)/1000) AS "Distance", 
    NULL AS "ProjectType",'Properties' As "Source", [GlobalRMArea] 
    FROM [BTSOne].[dbo].[Properties] 
    WHERE [Point].STDistance(@SearchPoint) <= (@intRadiusKm * 1000) 
    AND OpenStatus = 'Open' 
    ORDER BY "Distance" 

這是我會怎樣創建索引：

CREATE SPATIAL INDEX [SI_Property] ON [BTSOne].[dbo].[Properties] 
    (
     [Point] 
)USING GEOGRAPHY_GRID 
    WITH (GRIDS =(LEVEL_1 = HIGH,LEVEL_2 = HIGH,LEVEL_3 = HIGH,LEVEL_4 = HIGH),  
    CELLS_PER_OBJECT = 16, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,  SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
    GO 

我正在一個非常有限的訪問環境中工作，所以我沒有太多的嘗試和錯誤的奢侈品nd我沒有直接訪問sql服務器實例，所以我不想忍受我的重試限制:-)。

謝謝！

Answer 1

空間索引確實需要一點時間適應，但一旦你做了，它們就非常簡單。

首先，只能在空間列上創建空間索引 - 即那些類型爲GEOMETRY或GEOGRAPHY的空間索引。在你的實例中，你有一個單獨的列「[Point]」，所以這是你應該並且可以索引的唯一列。

運行涉及空間數據的查詢時，生成的查詢計劃通常非常高效，對WHERE子句的該部分使用空間索引，對WHERE子句的其他部分使用其他非空間索引。

至於網格層次，不幸的是它可能是反覆試驗，因爲它最終取決於您的數據。當你開始使用設置時，通常我發現你只能節省毫秒 - 在大多數情況下。從HHHH開始，每個物體16個細胞。如果對結果不滿意，請檢查查詢計劃以確保它正在被使用，如果是，請對其進行調整。

如果您確實想了解空間索引，我建議您查看Alistair Aitchison的「Pro Spatial with SQL Server 2012」。它確實是在SQL中使用Spatial數據的聖經，而Alistair在這方面做得非常出色。