抓住存在于某些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
…并猜测…查询立即运行.
解决方法
该查询正在对PK_States索引执行聚簇索引扫描.它没有使用空间索引.这是因为查询优化器认为使用聚簇索引而不是任何其他索引会更好.为什么？可能是因为州表中的行数很少(华盛顿,加州,波多黎各等地的50多个可能还有其他几行).
sql Server在8KB页面上存储和检索数据.筛选操作的行大小(请参阅估计行大小)为8052字节,这意味着每页有一行,整个表中有大约50页.查询计划估计它将处理这些行中的大约18行(请参阅估计行数).这不是要处理的大量行.我的解释没有解决作为表格一部分的额外页面,但重点是该数字大约为50而不是50,000页.
所以,回到为什么它使用PK_States索引而不是SPATIAL_States_Boundry索引.根据定义,聚簇索引包含表的实际数据.非聚集索引指向数据所在的页面,因此需要检索更多页面.因此,非聚集索引仅在存在大量数据时才有用.
您可以采取一些措施来减少进程的页数(例如,使用覆盖索引),但您当前的查询已经过很好的优化,并且您不会看到太多的性能提升.
