SQL Server 存储过程在给定相同输入的情况下每次执行时生成不同的结果集

xt0899hw  于 2023-01-12  发布在  其他
关注(0)|答案(1)|浏览(110)

我有一个存储过程,它根据一组可选的搜索条件返回一组分页的结果。该过程使用一个临时表,这样总计数和页数就可以与搜索结果分开返回。

CREATE PROCEDURE [dbo].[Location_SearchAll]
    @LocationName varchar(100) = null,
    @LocationId varchar(10) = null,
    @Address varchar(40) = null,
    @City varchar(35) = null,
    @StateProvince varchar(2) = null,
    @PostalCode varchar(9) = null,
    @CountryCode varchar(2) = null,
    @PhoneNumber varchar(20) = null,
    @ServiceLevel varchar(35) = null,
    @Page int = 1,
    @ItemsPerPage int = 100
AS
    select * into #temp from Locations l
        where (l.LocationName like '%' + @LocationName + '%' or @LocationName is null)
            and (l.LocationId like '%' + @LocationId + '%' or @LocationId is null)
            and (l.AddressLine1 like '%' + @Address + '%' or @Address is null)
            and (l.City like '%' + @City + '%' or @City is null)
            and (l.StateProvince like '%' + @StateProvince + '%' or @StateProvince is null)
            and (l.PostalCode like '%' + @PostalCode + '%' or @PostalCode is null)
            and (l.CountryCode like '%' + @CountryCode + '%' or @CountryCode is null)
            and (l.Phone like '%' + @PhoneNumber + '%' or @PhoneNumber is null)
            and (l.ServiceLevel like '%' + @ServiceLevel + '%' or @ServiceLevel is null);
    select count(*) as TotalCount, count(*) / @ItemsPerPage + 1 as TotalPages from #temp;
    select * from #temp
        order by Id
        offset (@Page) * @ItemsPerPage - @ItemsPerPage rows
        fetch next @ItemsPerPage rows only;
    drop table #temp;
RETURN 0
GO

我注意到,尽管定义了完全相同的搜索条件,但有时这个过程每次返回的结果数不同。结果计数将随着每次后续执行而稳定增加,直到计数最终达到根据搜索条件应返回的实际记录数为止。s,就好像在临时表完全填充之前由select语句返回结果一样。
一些注意事项:

  • 这种异常反映在两个select语句中-总计数和返回的结果。
  • 我尝试过用一个表变量替换临时表,但也有同样的问题。

我猜这是我在使用临时表方面做的一些愚蠢的事情,但是我似乎找不到任何文档来解释这可能是什么。有什么想法吗?提前感谢。

9lowa7mx

9lowa7mx1#

@Larnu是对的。这是我自己愚蠢的错误。我甚至没有考虑底层数据发生变化的可能性,因为这是一个本地数据库,没有其他人接触它,然后我想起我有一个周期性的ETL计划,每隔几分钟刷新一次表。这就是为什么我的结果集发生变化。
如果我可以删除这个问题并隐藏我的尴尬,我会的,但取而代之的是,我只想感谢@Stu对存储过程改进的简明指导,并希望我的derp时刻防止其他人犯同样的错误。

相关问题