给定空间索引，索引实用程序，即索引的整体性能，仅与整体几何体一样好。
例如，如果我要获取一百万个几何数据类型并将它们插入到表中以使它们的相对点彼此密切相关，这是否会使该索引对相对位置可能相同的几何形状执行得更好显着更加稀疏。
例如，采用这两种几何形状。
LINESTRING(0 0,1 1,2 2)
LINESTRING(1 1,2 2,3 3)
几何上它们是相同的，但它们的坐标是一个点。想象一下，重复了一百万次。
现在采取这种情况，
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)
在上面的例子中：
然而，
为什么这对我很重要？
我问这个问题的原因是因为我想知道我是否应该尽可能多地从输入几何中移除精度，并且尽可能减少它们的密度和彼此的接近程度，而不会失去准确性。
这个问题类似于第一个问题，但是不应该在空间上接近另一个几何形状，应该将形状本身缩小到最小可能的形状来描述应用程序所需的内容。
例如，如果我在几何数据类型上使用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”。
有人可以帮助填补这些空白吗？
答案 0 :(得分：1)
当插入新条目时，引擎会选择最小扩展的MBR。
通过“最小扩展”，引擎可以表示“区域扩展”或“周边扩展”，前者默认为MySQL。
这意味着只要您的节点具有非零区域，它们的绝对大小无关紧要：较大的MBR仍然较大而较小的MBR仍然较小，最终所有节点将最终相同的MBR s
您可能会对这些文章感兴趣：
对于密度，在页面拆分时重新计算MBR，并且很有可能在距离主群集太远的所有点将在第一次拆分时移动到他们自己的{{1 }}。它很大，但在几次迭代中成为所有优秀点的父级。
这将减少未完成点的搜索时间，并将通过一页搜索增加群集点的搜索时间。