问需要帮助优化可能出错的空间SQL查询

EN

Update：自从撰写这篇文章以来，我们决定将地理空间数据迁移到ElasticSearch数据库，从而获得更好的结果。

我对SQL很陌生，我需要帮助优化空间查询，使其在2秒内运行。我们已经尝试了一些建议，在不同的网站(更多关于这一点)。

背景

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

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)。

聚集索引查找详细信息：

​

​

空间索引寻求详细信息：

​

​

问题

不应该用空间索引，而不是聚集指数来完成繁重的工作吗？

可以通过更改空间索引的设置来改进查询吗？我们应该使用什么设置(网格、CELLS_PER_OBJECT等)？

如何从总体上缩短执行时间，或使这种查询的执行时间达到7-10秒呢？

我们所做的努力，帮助了我们

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

• 检查索引碎片，并重新生成索引。
• 从STIntersect()到Filter()的交换求交法
• 减少了输入几何与Reduce(.25)。这使得几何学从1442个数据点减少到7个(如果我们决定使用它，那么对于不同的输入，它必须是动态的，但这是另一个问题)。
• 引入了一个新的表列SimpleGeometry，它包含来自Geometry列的所有几何对象的边框。创建了一个新的SimpleGeometry空间索引，并使用SimpleGeometry代替Geometry进行查找。(在查询示例中不使用。)