Question

我们有一个在连接表中搜索的商店程序。我们有一个Production和Dev Sql服务器。存储过程在生产服务器上运行正常，但在Dev SQL服务器上，执行需要2分钟以上。我认为ROW Number是我们在Dev服务器上遇到性能问题的根本原因。

CREATE proc  sp_fullEmp 
@take int ,
@skip int 
as 

with main as (
select 
 dt.FirstName +' '+ dt.LastName [FullName],
 dt.[Location],
emp.FirstName + ' '+ emp.LastName [Manager],
dt.[ApplicationDate] 

from  ExtractedData dt 
left join ProcessTable tb
        left join Employee emp on emp.ID = tb.EmployeeID
 on td.ExtID = dt.ID),

searched as (select *, ROW_NUMBER() OVER (ORDER By FullName ASC) RN from main)

select * from searched where RN BETWEEN @skip AND @Take

同一查询的示例正在其他表上运行，在具有更大数据集的Dev和Production服务器上没有任何性能问题。

这个问题的根本原因是什么？

执行Dev Plan

执行Prod Plan

Answer 1

您的问题可能是参数嗅探。 SQL不知道@Skip和@Take会是什么，这可能会抛出计划。

值得比较Prod＆amp;开发 - 通常Dev数据可能更“笨拙”，特别是如果手动插入它。看看Avg，min和Max

是什么

尝试在存储过程中使用RECOMPILE，并查看是否有帮助。或者 - DBCC FREEPROCCACHE将清空proc缓存并创建一个新计划。

我刚刚意识到你没有对你的Row_Number（）查询进行分区 - 这意味着你实际上只是按Fullname运行一个TOP N查询顺序 - 看起来很奇怪，因为它会根据提取和员工的数量给出随机结果< / p>

ROW_NUMBER表现

1 个答案: