SQL 交叉应用性能问题

Question

我的数据库有一个目录，其中包含分布在美国各地的大约 2,000 个地点的邮政编码信息（我已将其与经度/纬度坐标相关联）。

我还有一个表格函数，它接受两个参数（ZipCode 和 Miles）来返回相邻邮政编码的列表（不包括搜索的相同邮政编码）

对于每个位置，我都在尝试获取相邻的位置 ID。因此，如果位置 #4 具有三个附近的位置，则输出应如下所示：

1. 4 5
2. 4 24
3. 4 137

也就是说，位置 5、24 和 137 位于位置 4 的 X 英里范围内。

我最初尝试对我的函数使用交叉应用，如下所示：

SELECT A.SL_STORENUM,A.Sl_Zip,Q.SL_STORENUM FROM tbl_store_locations AS A
CROSS APPLY (SELECT SL_StoreNum FROM tbl_store_locations WHERE SL_Zip in (select zipnum from udf_GetLongLatDist(A.Sl_Zip,7))) AS Q 
WHERE A.SL_StoreNum='04'

但是运行了 20 多分钟没有结果，所以我取消了它。我确实尝试在邮政编码中进行硬编码，它立即返回了一个列表

SELECT A.SL_STORENUM,A.Sl_Zip,Q.SL_STORENUM FROM tbl_store_locations AS A
CROSS APPLY (SELECT SL_StoreNum FROM tbl_store_locations WHERE SL_Zip in (select zipnum from udf_GetLongLatDist('12345',7))) AS Q 
WHERE A.SL_StoreNum='04'

完成此附近地点列表的最有效方法是什么？请记住，虽然我在这里使用“04”作为示例，但我想对 2,000 个位置进行分析。

“udf_GetLongLatDist”是一个函数，它使用一些数学计算两个地理坐标之间的距离，并返回一个距离大于 0 的邮政编码列表。其中没有什么花哨的。

Answer 1

当您使用该函数时，您可能必须计算每一行的每个可能的距离。这就是为什么需要这么长时间。由于实际的物理位置通常不会移动，所以我们一直做的是预先计算每个邮政编码与其他邮政编码的距离（并且当我们添加新的可能的邮政编码时大约每月更新一次）。预先计算好距离后，您所要做的就是运行类似

的查询

select zip2 from zipprecalc where zip1 = '12345' and distance <=10

Answer 2

我们有类似的东西，并通过仅计算纬度在有界范围内的其他邮政编码的距离来优化它。因此，如果您想在@miles 中使用其他拉链，请使用

where latitude >= @targetLat - (@miles/69.2) and latitude <= @targetLat + (@miles/69.2)

那么您只是在计算其他邮政编码行的一小部分子集的大圆距离。我们发现这个速度足够快，不需要预先计算。

由于赤道和极点之间经度所代表的距离不同，因此不能对经度进行相同的处理。

Answer 3

这里的其他答案涉及重新设计算法。我个人建议所有邮政编码的预先计算的地图相互对照。应该可以将此类优化嵌入到您现有的 udf 中，以最大程度地减少代码更改。

然而，查询的重构可能如下...

SELECT
  A.SL_STORENUM, A.Sl_Zip, C.SL_STORENUM
FROM
  tbl_store_locations                 AS A
CROSS APPLY
  dbo.udf_GetLongLatDist(A.Sl_Zip,7)  AS B
INNER JOIN
  tbl_store_locations                 AS C
    ON C.SL_Zip = B.zipnum
WHERE
  A.SL_StoreNum='04'

此外，如果您可以确保 udf 是 INLINE 而不是 MULTI-STATEMENT，则 CROSS APPLY 的性能将大大受益。这允许 udf 内联扩展（类似宏）以获得更清晰的执行计划。

这样做还可以让您从 udf 返回其他字段。然后，优化器可以根据您是否实际使用这些字段，在计划中包含或排除这些字段。这样的示例将包括 SL_StoreNum，如果它可以从 udf 中的查询轻松访问，那么就不需要最后一个连接...