距离计算效率 MSSQL 地理

Posted 2023-02-23

【中文标题】距离计算效率 MSSQL 地理

【英文标题】：Distance Calculation Efficiency MSSQL Geography

【发布时间】：2014-02-07 17:01:43

【问题描述】：

我有一个运行缓慢的 SQL 查询，我确定它与距离计算有关。 我使用这些计算进行排序，以便可以向正在寻找项目的用户提供在地理上最接近他们的结果。

我使用地理函数 STDistance 来计算与预先计算的 sql 地理数据类型位置的距离。

Location1.STDistance(Location2)

Location1是基于用户的位置，location2是物品的位置。

一旦我们进入数千行，这就会表现不佳，但我不知道有什么聪明的方法可以做到这一点。我认为存储所有可能的距离计算以供查找与在查询时计算是不可行的。 （这意味着存储唯一用户位置 X 唯一项目位置的数量。）

地点由邮政编码决定。地理范围仅限于美国。

还有其他想法吗？

【参考方案1】：

人们通常处理慢速地理查询的方式是将集合减少到足够小，以便可以在合理的时间内执行。在您的情况下，人们通常采用一种称为“地理拳击”的技术。

这个概念是找到位于特定纬度/经度边界内的附近点。例如。如果我想找到 42.45678、-22.6543 附近的所有人，我会首先确定典型的最小距离是多少。让我们假设它是 25 英里或 +- 0.15 度纬度和经度。我会查询所有这些。 （纬度在 41.95 和 42.95 之间，朗度在 -22.15 和 -23.15 之间）。然后我会应用距离函数来找到我减少的集合中最近的人。在我消除了明显不是很近的点之后，距离计算要快得多。

如果我的缩减集似乎太大，那么我可以使用一个较小的盒子。如果我的结果集没有返回行或返回的行太少，那么我可以使用递归算法来选择一个越来越大的框，直到找到足够大的结果集。

这种方法的唯一缺点是它可能会省略最近的点。想想一个接触盒子边缘的圆圈和一个圆圈内的盒子。框角上的点可能会被包括在内，但框外更近的点（在 x 轴或 y 轴上）可能会被排除在外。此外，当您远离赤道时，纬度/经度框实际上更像梯形而不是正方形。

无论如何，如果速度比完美的准确性更重要的话。地理拳击是一种需要考虑的方法。

【讨论】：

嗯，我喜欢这个，但我已经有了一个盒子，因为我有所有邮政编码的纬度，经度，甚至认为这不是很精确，它缩小了已经计算过了。