问相同的查询在服务器A上需要0秒，在服务器B上需要7.5分钟(相同的db/ Same /config)

EN

我有一个查询(下面的sql)，它在1台服务器上几乎是瞬时的，但在另一台几乎相同(关键点)的服务器上需要7.5分钟。估计的查询执行计划有一个明显的区别；在执行速度较慢的服务器上的计划包含一个"Index Spool (急切的Spool)“，而在执行速度较快的服务器上的计划没有。

服务器F(快速)-服务器S的快照，每月刷新。只有少数用户使用它来进行密集的分析，并且已经被分离了，所以每天的用户都不必受到性能的影响。

服务器S(慢速)-接收每日数据更新，通常用于即席数据挖掘和少量的用户工作流数据更新。当此sql运行7.5分钟时，没有用户活动或进程正在运行。

硬件和配置是相同的。一个不同之处是，服务器B上的索引每周只重建一次/重新组织一次。它们是在服务器F上恢复快照后重新生成的。但我不认为这是个问题，因为在服务器S上，大型IB收费表上的所有索引碎片都是< 5%。

sql可能是复杂的或丑陋的，但它在1服务器上运行得很快。在速度较慢的服务器上，索引碎片似乎并不比在较慢服务器上的碎片高得多。

是什么造成了如此巨大的差异？我很难决定下一步要调查什么。

select 
row_number() over (order by t1.service_date) as rank,
sum(t1.total_charge) total_charge,
sum(t1.service_units) service_units,
t1.service_date service_date,
(   select sum(x.total_charge)
    from ib_charge x
            inner join ib_header y on x.ib_header_fk = y.ib_header_pk
    where x.patient_account_fk = ### 
            and x.record_type = 1
            and x.voided = 0
            and y.replaced = 0
            and x.revenue_code not in (274, 275, 276, 278)
        and (x.service_date is null or x.service_date <= t1.service_date)
    ) running_total_by_day
from
ib_charge t1
inner join ib_header t2 on t1.ib_header_fk = t2.ib_header_pk
where
t1.patient_account_fk = ###
and t1.record_type = 1
and t1.voided = 0
and t2.replaced = 0
and t1.revenue_code not in (274, 275, 276, 278) 
group by t1.service_date
order by t1.service_date

执行计划服务器F 服务器_F.sqlplan

执行计划服务器S 服务器_S.sqlplan

服务器F统计数据io

(55 row(s) affected)

Table 'IB_Header'. Scan count 0, logical reads 60611, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'IB_Charge'. Scan count 56, logical reads 121156, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

服务器S统计

(55 row(s) affected)

Table 'IB_Header'. Scan count 0, logical reads 60706, physical reads 0, read-ahead reads 2, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'Worktable'. Scan count 55, logical reads 384302241, physical reads 12, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'IB_Charge'. Scan count 2, logical reads 1686771, physical reads 4143, read-ahead reads 1684432, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

更新>>我也把这个问题作为一个办公室的挑战，在星期一有人祝贺我解决了这个问题--但我什么也没做！一周一次的统计刷新和索引重建已经运行了整个周末，但是所涉及的表上的特定索引统计数据看起来并没有太大的不同。在进一步研究时，我意识到，根据查询的###部分中使用的特定键，结果将花费0秒钟或5-8分钟。仅仅编辑键还会导致估计的执行计划包括/排除索引假脱机，这似乎是查询的主要延迟。目前正在对bpool进行更全面的调查。