sql-server-2008 – 如何加速这个Sql Server Spatial查询？

我(我认为)是一个简单的sql Server空间查询：

抓住存在于某些4边多边形内的所有美国国家(即网页的谷歌/ bing地图的视口/边界框)

SELECT CAST(2 AS tinyint) AS LocationType,a.Name AS FullName,StateId,a.Name,Boundary.STAsText() AS Boundary,CentrePoint.STAsText() AS CentrePoint
FROM [dbo].[States] a
WHERE @BoundingBox.STIntersects(a.Boundary) = 1

运行需要6秒钟:(

这是执行计划….

删除

过滤操作的统计数据……

删除

现在,我只是不确定如何调试这个..弄清楚我需要微调等等.我有任何空间索引吗？我相信是这样 …

/****** Object:  Index [SPATIAL_States_Boundary]    
        Script Date: 07/28/2010 18:03:17 ******/
CREATE SPATIAL INDEX [SPATIAL_States_Boundary] ON [dbo].[States] 
(
    [Boundary]
)USING  GEOGRAPHY_GRID 
WITH (
    GRIDS =(LEVEL_1 = HIGH,LEVEL_2 = HIGH,LEVEL_3 = HIGH,LEVEL_4 = HIGH),CELLS_PER_OBJECT = 1024,PAD_INDEX  = OFF,SORT_IN_TEMPDB = OFF,DROP_EXISTING = OFF,ALLOW_ROW_LOCKS  = ON,ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
GO

我是否需要提供有关返回的GEOGRAPHY数据的更多信息？例如.分数等？或者我需要运行探查器并从那里提供一些统计数据？

或者我的Cells_per_object /网格设置不正确(我真的不知道我应该将这些值设置为TBH).

有人可以帮忙吗？请？

UPDATE /编辑：

从@Bobs下面的第一个回复确认空间索引没有被使用,因为主键(聚簇索引)比50个奇数行的表上的非聚集索引更快…然后我试图强制空间索引(对于shits-n-giggles)： –

SELECT CAST(2 AS tinyint) AS LocationType,CentrePoint.STAsText() AS CentrePoint
FROM [dbo].[States] a WITH (INDEX(SPATIAL_States_Boundary))
WHERE @BoundingBox.STIntersects(a.Boundary) = 1

…并猜测…查询立即运行.

WTF？其他人都知道为什么？我是否还需要发布查询计划,以帮助解释原因/内容？

解决方法

您似乎有一个运行查询的最佳计划.改善这一点很难.以下是一些观察结果.

该查询正在对PK_States索引执行聚簇索引扫描.它没有使用空间索引.这是因为查询优化器认为使用聚簇索引而不是任何其他索引会更好.为什么？可能是因为州表中的行数很少(华盛顿,加州,波多黎各等地的50多个可能还有其他几行).

sql Server在8KB页面上存储和检索数据.筛选操作的行大小(请参阅估计行大小)为8052字节,这意味着每页有一行,整个表中有大约50页.查询计划估计它将处理这些行中的大约18行(请参阅估计行数).这不是要处理的大量行.我的解释没有解决作为表格一部分的额外页面,但重点是该数字大约为50而不是50,000页.

所以,回到为什么它使用PK_States索引而不是SPATIAL_States_Boundry索引.根据定义,聚簇索引包含表的实际数据.非聚集索引指向数据所在的页面,因此需要检索更多页面.因此,非聚集索引仅在存在大量数据时才有用.

您可以采取一些措施来减少进程的页数(例如,使用覆盖索引),但您当前的查询已经过很好的优化,并且您不会看到太多的性能提升.

原文地址：https://www.jb51.cc/mssql/84385.html