tSQL 超时地理查询



我得到一个随机/间歇性的SQL超时,看起来它从一个简单的查询中生成了大量的处理。 这是正确的行为吗?

我有一个简单的存储过程,如下所示:

CREATE PROCEDURE [dbo].[FindClosestXNearCoordinates]
      @latitude decimal,
      @longitude decimal
   AS
BEGIN
SET NOCOUNT ON;
declare @emptyGUID uniqueidentifier
set @emptyGUID = cast(cast(0 as binary) as uniqueidentifier)
declare @radiusInMeters float
set @radiusInMeters = 3500 * 1609.344   
declare @coordinatePoint as Geography   
SET @coordinatePoint = geography::STGeomFromText('POINT(' + CAST(@longitude AS VARCHAR(20)) + ' ' + CAST(@latitude AS VARCHAR(20)) + ')', 4326)
declare @coordinateRadius as Geography
set @coordinateRadius = @coordinatePoint.STBuffer(@radiusInMeters);

select  top 1   [b].[BaseId], [b].[Code], [b].[Name], [b].[Location], [b].[TerritoryId], [b].[Latitude], [b].[Longitude]
from        XTable b
where       ( b.GeoLocation.STIntersects(@coordinateRadius) = 1 )
order by b.GeoLocation.STDistance(@coordinatePoint) asc
END

我在 SQL 事件探查器中捕获它,它连续显示查询和超过 188 个语句,这真的很令人困惑,因为当我在 SSMS 中运行它时,它只显示 1 个执行,但在应用程序中运行会生成 188 个子语句。

首先是SQL探查器。由于空间类型对 SQL 服务器来说有些特殊,因此它们会产生额外的处理。它为同一个 TSQL 语句多次注册 SP:Start 和 SP:已完成条目,因为它只能在 TSQL 级别报告操作。你只需要忍受这一点。在 SQL Server 2012 中也是如此。

关于您的查询超时,我建议用更基本的测试替换 STIntersect(),使条件

where (b.longitude between @longitude-@xdelta and @longitude+@xdelta)
  and (b.latitude between @latitude-@ydelta and @latitude-@ydelta)
order by b.GeoLocation.STDistance(@coordinatePoint) asc

关键是通过将米转换为十进制值来找出合适的@xdelta。转换目前逃脱了我,但谷歌是你的朋友。 如果你真的需要,你甚至可以添加STIntersect(buffer)。

最新更新