Sql server 2008 如何加快此Sql Server空间查询的速度？

我有（我认为）一个简单的Sql Server空间查询：

抓取存在于某个四边形中的所有美国州（即网页谷歌/必应地图的视口/边界框）

运行需要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

我是否需要提供有关返回的

地理信息

数据的更多信息？例如点数等？或者我是否需要运行

探查器

并从中提供一些统计信息

或者我的每个对象/网格的单元格设置不正确（我真的不知道应该将这些值设置为什么，TBH）

有人能帮忙吗

更新/编辑： 在下面@Bobs的第一个回复确认空间索引没有被使用后，因为主键（聚集索引）将比50多行表上的非聚集索引快…然后我尝试强制空间索引（对于shits-n-giggles）：-

…猜怎么着..查询会立即运行

---

WTF？还有人知道为什么吗？我是否需要发布一个查询计划来帮助解释为什么/什么？

看来您有一个运行查询的最佳计划。这方面很难改进。下面是一些观察结果

查询正在对PK_状态索引进行聚集索引扫描。它没有使用空间索引。这是因为查询优化器认为使用聚集索引而不是任何其他索引会更好。为什么？可能是因为状态表中的行很少（华盛顿特区、波多黎各等地可能还有50多人）

SQL Server在8KB页面上存储和检索数据。筛选操作的行大小（请参阅估计行大小）为8052字节，这意味着每页有一行，整个表中约有50页。查询计划估计它将处理其中约18行（请参阅估计行数）。要处理的行数不多。我的解释并没有说明作为表一部分的额外页面，但重点是该数字大约为50页，而不是50000页

那么，回到为什么它使用PK_States索引而不是space_States_Boundry索引。根据定义，聚集索引包含表的实际数据。非聚集索引指向数据所在的页面，因此有更多的页面需要检索。因此，非聚集索引只有在数据量较大时才有用大量的数据

---

您可能可以做一些事情来减少进程的页数（例如，使用覆盖索引），但您当前的查询已经得到了很好的优化，您不会看到太多性能改进。

尝试此操作，并显示索引提示：

EXEC sp_executesql N'
  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'
, N'@BoundingBox GEOGRAPHY', @BoundingBox

如果有任何不同，请参阅以了解更多详细信息：

如果您正在SSMS中运行代码， 在空间数据库中使用sp_executesql 查询（或使用自己存储的 将空间值作为 参数）以确保查询coster “知道”当前位置的参数值 在创建查询计划时 是，在批次开始时还是在 存储过程的条目或 sp_executesql

---

为详细的回答干杯。我真的非常感谢：）还有几个问题：如果查询优化器决定使用聚集索引-kewl。你说得对。该表中只有大约56行。那么为什么需要这么长时间？我是否可以看到吞吐量受到影响的其他方面：（如果不是查询..还能是什么？（服务器不是100%运行，顺便说一句）。我还用更多信息更新了最初的帖子。。在底部的“编辑/更新”下。你能重读一下吗？这很有趣，空间索引工作得很好。我怀疑使用聚集索引评估空间条件的性能不如使用空间索引快。出于测试目的，你可以ght在非空间列上尝试非聚集索引，并运行使用此列的查询。然后，查看该查询与以前的查询相比如何。查看没有空间逻辑的查询的执行情况会很有趣。有趣…因此我将其移动到存储过程中，并传入boundingBox变量。现在是9秒没有使用索引。这是在SQL 2008 R2/10.50 RTM上。另外，在SSMS中运行它（如上所述）会在9秒内返回，没有使用索引，并将上面的代码放入一个存储过程中，并传入BoundingBox变量。同样地，也会这样做。：（这很有趣。您可能还会玩w./

.Filter（）

，如果您还没有的话。我经常发现自己在临时表中具体化

.Filter（）

的结果，然后在此基础上执行更精确的操作。此外，我建议在上交叉发布。对于SQL Server空间问题，那里的读者群要好得多。

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 WITH (INDEX(SPATIAL_States_Boundary))
WHERE @BoundingBox.STIntersects(a.Boundary) = 1

EXEC sp_executesql N'
  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'
, N'@BoundingBox GEOGRAPHY', @BoundingBox