由于计算列,Azure SQL Server空间索引错误无法创建...

威尔·洛佩兹(Will Lopez)

[更新]我尝试了下面的索引定义,并收到以下错误消息:

  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

我在非常有限的访问环境中工作,所以我没有太多尝试和错误的机会,而且我无法直接访问sql服务器实例,所以我不想浪费我的重试时间限制 :-)。

谢谢!

乔恩·贝拉米

空间索引确实需要一点时间来适应,但是一旦完成,它们就会非常简单。

首先,只能在Spatial列上创建空间索引-即类型GEOMETRYGEOGRAPHY在您的实例中,您只有一个列“ [Point]”,因此这是您应该并且可以索引的唯一列。

当运行涉及空间数据的查询时,生成的查询计划通常非常高效,使用WHERE子句那部分的空间索引和WHERE子句其他部分的其他非空间索引。

至于网格级别,不幸的是,它可能是反复试验的,因为最终它取决于您的数据。但是,当您开始使用这些设置时,通常我发现您只节省了毫秒-在大多数情况下。从HHHH开始,每个对象16个单元格。如果您对结果不满意,请检查查询计划以确保其正在使用,如果需要,请对其进行调整。

如果您真的想了解空间索引,建议您阅读Alistair Aitchison的“使用SQL Server 2012的Pro Spatial” 这确实是在SQL中使用空间数据的圣经,而Alistair的工作做得非常出色。

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章