SPATIAL 几何索引性能是否取决于几何形状的大小和密度？

Question

空间索引

给定一个空间索引，是索引效用，也就是说索引的整体性能，仅与整体几何形状一样好。

例如，如果我要采用一百万个几何数据类型并将它们插入到表中，以便它们的相对点彼此密集，这是否会使该索引对于相对位置可能明显更加稀疏的相同几何形状表现更好。

问题1

例如，以这两个几何形状为例。

情况 1

LINESTRING(0 0,1 1,2 2)
LINESTRING(1 1,2 2,3 3)

从几何角度看，它们是相同的，但它们的坐标有一点偏差。想象一下这被重复了一百万次。

现在采用这种情况，

情况 2

LINESTRING(0 0,1 1,2 2)
LINESTRING(1000000 1000000,1000001 10000001,1000002 1000002)
LINESTRING(2000000 2000000,2000001 20000001,2000002 2000002)
LINESTRING(3000000 3000000,3000001 30000001,3000002 3000002)

在上面的示例中：

• 线的尺寸与情况 1 相同，
• 线的点数相同，
• 线的尺寸相同。

然而，

• 区别在于，线条之间的距离非常远。

---

为什么这对我很重要？

我问这个问题的原因是因为我想知道是否应该尽可能地从输入几何图形中删除精度并降低它们的密度和彼此的接近度我的应用程序可以在不损失准确性的情况下提供尽可能多的信息。

问题 2

这个问题与第一个问题类似，但不是在空间上接近另一个几何形状，而是应该将形状本身简化为尽可能小的形状来描述应用程序所需的内容。

例如，如果我要在几何数据类型上使用 SPATIAL 索引来提供日期数据。 如果我想存储两个日期的日期范围，我可以在 mysql 中使用日期时间数据类型。但是，如果我想使用几何类型，以便通过获取每个单独的日期并将其转换为 unix_timestamp() 来传递日期范围，该怎么办？

例如：

 Date("1st January 2011") to Timestamp =  1293861600
 Date("31st January 2011") to Timestamp =  1296453600

现在，我可以根据这两个整数创建一个 LINESTRING。

 LINESTRING(1293861600 0,1296453600 1)

如果我的应用程序实际上只关心天数，并且秒数对于日期范围根本不重要，那么我是否应该重构我的几何图形，以便将它们减小到尽可能小的大小以满足它们的需求。

因此，我将使用“1293861600”/(3600 * 24)，而不是“1293861600”，它恰好是“14975.25”。

有人可以帮助填补这些空白吗？

Answer 1

插入新条目时，引擎会选择最小扩展的MBR。

通过“最小扩展”，引擎可以表示“区域扩展”或“周界扩展”，前者是 MySQL 中的默认值。

这意味着只要您的节点具有非零面积，它们的绝对大小并不重要：较大的 MBR 保持较大，较小的保持较小，最终所有节点都将位于相同的 MBR

您可能会对这些文章感兴趣：

• MySQL 中的重叠范围
• 在重叠的日期范围上加入

至于密度，MBR在页面分割时重新计算，并且很有可能所有点都太远远离主集群的部分将在第一次拆分时移至其自己的 MBR。它会很大，但在几次迭代中就会成为所有突出点的父级。

这将减少突出点的搜索时间，并增加一页搜索的聚类点的搜索时间。