需要帮助来优化可能错误的空间SQL查询

Question

更新 ：自撰写本文以来，我们决定将我们的地理空间数据迁移到ElasticSearch数据库，从而产生更好的结果。

我是SQL的新手，我需要帮助来优化空间查询，以便它在2秒内运行。 我们已经在各个网站上尝试了一些建议（更多内容见下文）。

背景

我们有一个表[Id，Geometry]，大约300,000个不同大小和复杂度的几何形状，存储为几何数据类型。 我们使用下面的代码片段为Geometry创建了一个空间索引。

CREATE SPATIAL INDEX [IX_Geometry_Spatial]
ON [dbo].[Geometries] ([Geometry]) USING  GEOMETRY_AUTO_GRID 
WITH  (
        BOUNDING_BOX = (XMAX = 24.43359375, XMIN = 10.810546875, YMAX = 69.2249968541159, YMIN = 55.2791152920156)
      );

我们想要的是找到与输入几何形状相交的所有几何形状。 这是通过使用以下查询完成的。

DECLARE @g geometry;  
SET @g = geometry::STGeomFromText('POLYGON ((x0 y0, ...))', 4326); -- A Worst Case Polygon containing 1442 data points

SELECT Count(Id)
FROM Geometries
WHERE Geometries.Geometry.Filter(@g.Reduce(.25)) = 1

对于某些最坏情况的输入几何形状（大的，复杂的多边形），这种执行大约需要7-10秒。

这是查询的执行计划：

我们可以看到我们击中了空间索引，但最昂贵的操作是clustered index seek (Clustered)

聚集索引寻求详细信息：

空间索引寻求细节：

问题

不应该通过空间索引而不是聚集索引来完成繁重的工作吗？

可以通过更改空间索引的设置来改进查询吗？ 我们应该使用什么设置（对于GRIDS，CELLS_PER_OBJECT等）？

如何将整个执行时间缩短，或者这种查询可以达到7-10秒？

我们尝试了什么，这有帮助

每个都节省了大约几秒钟。

• 检查索引碎片和重建索引。
• 从STIntersect()到Filter()交换方法
• 使用Reduce(.25)减少输入几何Reduce(.25) 。 这将几何从1442个数据点减少到7.（如果我们决定使用它，它必须是不同输入的动态，但这是另一个问题。）
• 引入了一个新的表格列SimpleGeometry ，其中包含Geometry列中所有几何对象的边界框。 创建了一个新的SimpleGeometry空间索引，并使用SimpleGeometry进行查找而不是Geometry 。 （在查询示例中未使用。）

Answer 1

如果您在每次添加新形状时进行计算，然后仅将交叉点存储在表格中，该怎么办？ 现在您的查询是即时的。