执行聚簇索引查询与扫描的查询性能降低

Question

出于某种原因，下面的第二个查询比第一个查询运行得慢得多，即使它正在对集群密钥进行索引搜索。

数据库大小： 数据 - 20GB（仅使用15GB） 日志 - 20GB（仅使用700mb）

分区 - 186（由ENdTransDateTime列分区）

如果从查询中删除了EndTransDateTime过滤器，优化器将执行索引扫描，并在几秒钟内返回查询（而不是分钟）。

仅供参考 - 我完全无法控制查询，因为这些查询是由应用程序生成的。这显然是一致的行为 - 如果应用日期文件管理器，查询将运行很长时间。移除后，它会在几秒钟内执行。我已经给了一些例子可以使用。以下只是一个例子：

- 此查询需要大约2.2分钟才能执行

 SELECT TOP 1000  [t5].[StoreNo] AS [Store_No], [t5].[Name] AS [Store_Name], [t5].[CashierNo] AS [Cashier_No], [t5].[TradingDay] AS [Trading_Day], [t5].[value] AS [Unique_Count_of_Results], [t5].[value2] AS [Count_of_Results]
FROM (
    SELECT DISTINCT [t4].[StoreNo], [t4].[Name], [t4].[CashierNo], [t4].[TradingDay], [t4].[value], [t4].[value2]
    FROM (
        SELECT COUNT_BIG(DISTINCT [t0].[TransactionID]) AS [value], COUNT_BIG(*) AS [value2], [t0].[StoreNo], [t3].[Name], [t0].[CashierNo], [t0].[TradingDay]
        FROM [CRDMPointOfSale].[dbo].[CRDM_Header] AS [t0]
        INNER JOIN [CRDMPointOfSale].[dbo].[CRDM_Item] AS [t1] ON [t0].[TransactionID] = [t1].[TransactionID]
        INNER JOIN [CRDMPointOfSale].[dbo].[CRDM_Tender] AS [t2] ON [t1].[TransactionID] = [t2].[TransactionID]
        INNER JOIN [GAME_ReferenceData].[dbo].[Ref_LocationHierarchy] AS [t3] ON [t2].[StoreNo] = [t3].[StoreNo]
        WHERE ([t0].[TicketAmount] < 0) AND (([t1].[ReturnType] = 2) OR ([t1].[ReturnType] = 1) OR ([t1].[ReturnType] = 21)) AND ([t2].[MediaNo] = 1) AND ([t2].[MediaNo] <> 2) AND ([t2].[MediaNo] <> 8) AND ([t2].[MediaNo] <> 4) AND ([t2].[MediaNo] <> 3) AND ([t2].[MediaNo] <> 13) AND ([t2].[MediaNo] <> 12) AND ([t2].[MediaNo] <> 11) AND ([t2].[MediaNo] <> 6) AND ([t2].[MediaNo] <> 7) AND ([t2].[MediaNo] <> 99) AND ([t2].[MediaNo] <> 14) AND ([t2].[MediaNo] <> 5) AND ([t2].[MediaNo] <> 9) AND (NOT ([t1].[WasCanceledFlg] = 1)) AND (NOT ([t1].[CancelFlg] = 1)) 
        AND ([t0].[EndTransDateTime] > '20180418 23:59:59') AND ([t0].[EndTransDateTime] < '20180613 23:59:59') 
        AND ([t0].[StoreNo] <> 889)
        GROUP BY [t0].[StoreNo], [t3].[Name], [t0].[CashierNo], [t0].[TradingDay]
        ) AS [t4]
    ) AS [t5]
ORDER BY [t5].[value] DESC

- 此查询大约需要2秒钟 - 唯一的变化是在WHERE子句中注释掉EndTransDateTime过滤器

 SELECT TOP 1000  [t5].[StoreNo] AS [Store_No], [t5].[Name] AS [Store_Name], [t5].[CashierNo] AS [Cashier_No], [t5].[TradingDay] AS [Trading_Day], [t5].[value] AS [Unique_Count_of_Results], [t5].[value2] AS [Count_of_Results]
FROM (
    SELECT DISTINCT [t4].[StoreNo], [t4].[Name], [t4].[CashierNo], [t4].[TradingDay], [t4].[value], [t4].[value2]
    FROM (
        SELECT COUNT_BIG(DISTINCT [t0].[TransactionID]) AS [value], COUNT_BIG(*) AS [value2], [t0].[StoreNo], [t3].[Name], [t0].[CashierNo], [t0].[TradingDay]
        FROM [CRDMPointOfSale].[dbo].[CRDM_Header] AS [t0]
        INNER JOIN [CRDMPointOfSale].[dbo].[CRDM_Item] AS [t1] ON [t0].[TransactionID] = [t1].[TransactionID]
        INNER JOIN [CRDMPointOfSale].[dbo].[CRDM_Tender] AS [t2] ON [t1].[TransactionID] = [t2].[TransactionID]
        INNER JOIN [GAME_ReferenceData].[dbo].[Ref_LocationHierarchy] AS [t3] ON [t2].[StoreNo] = [t3].[StoreNo]
        WHERE ([t0].[TicketAmount] < 0) AND (([t1].[ReturnType] = 2) OR ([t1].[ReturnType] = 1) OR ([t1].[ReturnType] = 21)) AND ([t2].[MediaNo] = 1) AND ([t2].[MediaNo] <> 2) AND ([t2].[MediaNo] <> 8) AND ([t2].[MediaNo] <> 4) AND ([t2].[MediaNo] <> 3) AND ([t2].[MediaNo] <> 13) AND ([t2].[MediaNo] <> 12) AND ([t2].[MediaNo] <> 11) AND ([t2].[MediaNo] <> 6) AND ([t2].[MediaNo] <> 7) AND ([t2].[MediaNo] <> 99) AND ([t2].[MediaNo] <> 14) AND ([t2].[MediaNo] <> 5) AND ([t2].[MediaNo] <> 9) AND (NOT ([t1].[WasCanceledFlg] = 1)) AND (NOT ([t1].[CancelFlg] = 1)) 
        --AND ([t0].[EndTransDateTime] > '20180418 23:59:59') AND ([t0].[EndTransDateTime] < '20180613 23:59:59') 
        AND ([t0].[StoreNo] <> 889)
        GROUP BY [t0].[StoreNo], [t3].[Name], [t0].[CashierNo], [t0].[TradingDay]
        ) AS [t4]
    ) AS [t5]
ORDER BY [t5].[value] DESC

我有两者的执行计划，但我不确定如何上传它们？我能做到这一点吗？ （在代码块中试过但是xml文档太大了）

一旦我加载了执行计划，我将不胜感激如何解决问题所在。我已经在查询中为表运行了UPDATE统计信息。

我们有许多客户在相同的设置上使用TB的数据而没有性能问题。我不知道在哪里看/做什么等尝试去理解这里发生的事情。

谢谢

以下是2个聚集索引的一些屏幕截图（每个长时间运行的查询都有39％）。具有讽刺意味的是，引用的EndTransDateTIme过滤器位于“CRDM_Header”表中。

以下是查询计划（真棒实用程序）： 2秒查询： https://www.brentozar.com/pastetheplan/?id=H1VmIj1bm

2.2分钟查询： https://www.brentozar.com/pastetheplan/?id=rJ5FLsJWQ