筛选最近的行时，SQL查询花费很长时间

Question

我有这个SQL查询，但是我发现它最多可能需要11秒钟才能运行。我真的很困惑，因为当我将日期选择更改为2018年时，它会立即返回。

以下是查询：

select
    cv.table3ID, dm.Column1 ,dm.Column2, mm.Column1, 
    convert(varchar, cv.Date, 107) as Date, 
    mm.table2ID, dm.table1ID, mm.Column2,
    count(ctt.table4ID) as Total
from
    table1 dm
inner join 
    table2 mm on mm.table2ID = dm.table1ID
inner join 
    table3 cv on cv.table3ID = mm.table2ID
left join 
    table4 ct on ct.table4CVID = cv.table3ID
inner join 
    table4 ctt on ctt.table4MMID = mm.table2ID
where
    ctt.table4Date >= '2019-01-19'
    and ct.table4CVID is null  
    and dm.Column1 like '%Albert%'
    and cv.Column1 = 39505 
    and cv.Status = 'A'  
group by
    cv.table3ID, dm.Column1 ,dm.Column2, mm.Column1, 
    cv.Date, mm.table2ID, dm.table1ID, mm.Column2

我发现当我使用ctt.table4Date> ='2018-01-19'执行该查询时，响应是立即的。但是使用'2019-01-19'则需要11秒。

最初，当我发现查询花了11秒钟时，我以为它必须是索引问题，但是我不确定它是否与索引有关，因为它在较旧的日期执行得很好。

我查看了日期不同的查询的执行计划，它们看起来完全不同。

对为什么会发生这种情况有任何想法吗？与更新统计信息有关吗？

[更新]

下图是table4 ctt在2018年和2019年之间执行计划的比较。根据执行计划，这将占2018年运营商成本的43％和2019年占45％。 Execution Plan comparison of table4 ctt 2019 and 2018. Top is 2019, bottom is 208

这里的图像再次是对table4作为ct的执行计划的比较。同样，顶部是2019，底部是2018。 Execution plan of table4 ct comparison 2019 and 2018. Top is 2019, bottom is 208

[更新2]

以下是SQL执行计划：

使用“ 2018-01-19”作为日期时：https://www.brentozar.com/pastetheplan/?id=SyUh8xXQV

使用“ 2019-01-19”作为日期时：https://www.brentozar.com/pastetheplan/?id=rkELW1Q7V

Answer 1

最有可能的问题是，从其他表返回了更多的行。与[更新]链接的聚簇索引扫描仅显示聚簇索引搜索。

但是，您确实需要认识到索引查找被调用的次数是144。实际读取的行数是8位，这导致响应缓慢。

我猜测，当这对您来说很好时，此表上的实际执行次数将为1。144在这里杀死了您；给穷人找谓语。如果您知道适合您的查询计划，并且已经存在可以对其进行备份的索引，则应强制执行计划，并给出明确的提示以特定顺序加入。

修改

看看共享计划，将日期更改为2018可以更快地完成，因为在给定要处理的数据量的前提下，SQL切换为使用哈希匹配代替循环联接。