相同的查询，相同的数据库，不同的执行计划和执行的时间显着不同

Question

我遇到了一个问题，我无法理解。我们正在运行SQL Server 2012.我遇到了一对基本相同的查询，这些查询产生不同的执行计划，并且执行的时间显着不同（1秒比40+秒）...并且他们甚至返回完全相同的记录。它们之间唯一的区别是记录被查询的类别。

该查询在1秒钟内运行：

SELECT P.idProduct, P.sku, P.description, P.price, P.listhidden, P.listprice, P.serviceSpec, P.bToBPrice, P.smallImageUrl,P.noprices,P.stock, P.noStock,P.pcprod_HideBTOPrice,P.pcProd_BackOrder,P.FormQuantity,P.pcProd_BTODefaultPrice,cast(P.sDesc as varchar(8000)) sDesc, 0, 0, P.pcprod_OrdInHome, P.sales, P.pcprod_EnteredOn, P.hotdeal, P.pcProd_SkipDetailsPage 
FROM products P INNER JOIN categories_products CP ON P.idProduct = CP.idProduct 
WHERE CP.idCategory=494 AND active=-1 AND configOnly=0 and removed=0 AND formQuantity=0 
AND ((SELECT TOP 1 SP.stock FROM products SP WHERE SP.pcprod_ParentPrd = P.idProduct AND SP.description LIKE N'%(9-12 Months)' AND SP.removed=0) > 0) 
ORDER BY P.description Asc 

第二个运行40秒多，但唯一的区别是idCategory查询：

SELECT P.idProduct, P.sku, P.description, P.price, P.listhidden, P.listprice, P.serviceSpec, P.bToBPrice, P.smallImageUrl,P.noprices,P.stock, P.noStock,P.pcprod_HideBTOPrice,P.pcProd_BackOrder,P.FormQuantity,P.pcProd_BTODefaultPrice,cast(P.sDesc as varchar(8000)) sDesc, 0, 0, P.pcprod_OrdInHome, P.sales, P.pcprod_EnteredOn, P.hotdeal, P.pcProd_SkipDetailsPage 
FROM products P INNER JOIN categories_products CP ON P.idProduct = CP.idProduct 
WHERE CP.idCategory=628 AND active=-1 AND configOnly=0 and removed=0 AND formQuantity=0 
AND ((SELECT TOP 1 SP.stock FROM products SP WHERE SP.pcprod_ParentPrd = P.idProduct AND SP.description LIKE N'%(9-12 Months)' AND SP.removed=0) > 0) 
ORDER BY P.description Asc 

他们甚至返回完全相同的记录完全相同的顺序。

为第一查询执行计划：

的第二查询执行计划：

[编辑]这里的计划是实际，而不是估计，执行计划。

categories_products表是一个简单的查找表，只有两个字段idCategory和idProduct。即使是返回的记录也完全一样（只是碰巧SP.description LIKE N'%(9-12 Months)'，同样的产品被分配到这两个类别）。两者之间唯一的另一个区别是CP.idCategory 628是在今天早上刚刚创建的（但我没有看到可能会产生什么差异）。 [编辑：但是这正是没赚差价]

怎么能这样呢？如何简单地改变这里查询的CP.idCategory会产生一个不同的执行计划，更重要的是：它是如何执行40倍的执行时间？

最终，我不知所措弄清楚如何改善因为有两个，我可以理解没有本质区别，第二查询的可怕表现。

Answer 1

这个问题description列。 idCategory [628]的长度为description，长度大于idCategory [494]。因为你正在使用SP.description LIKE N'%(9-12 Months)'。 description的长度太长，那么你慢慢来。

而且你正在使用ORDER BY P.description Asc。

Answer 2

[1]看来，两个不同的类别可以有不同的最优的执行计划。在这种情况下，SQL Server似乎认为最适合idCategory=494的XP不是最优的idCategory=628（WHERE CP.idCategory=494/WHERE CP.idCategory=628）。这个问题的

根源似乎是一个事实，即dbo.products表没有一个聚集索引。首先测试将是这样创造的CIX：

CREATE UNIQUE CLUSTERED INDEX IUC_products 
ON dbo.products(UniqueColumn_ID) 

如果经过反复试验，性能好两个查询我将取代dbo.products用CLUSTERED PRIMARY KEY的NONCLUSTERED PRIMARY KEY第一滴速上述指数（一个表卡恩” t有两个或更多的聚集索引）。

[2]此外，我将重写以下子查询

AND ((SELECT TOP 1 SP.stock FROM products SP WHERE SP.pcprod_ParentPrd = P.idProduct AND SP.description LIKE N'%(9-12 Months)' AND SP.removed=0) > 0) 

从而：

AND EXISTS(SELECT * FROM products SP WHERE SP.pcprod_ParentPrd = P.idProduct AND SP.description LIKE N'%(9-12 Months)' AND SP.removed=0 AND SP.stock > 0) 

和用于此子查询我想创建以下非聚集索引

[3]

CREATE NONCLUSTERED INDEX IX_product_pcprod_ParentPrd_removed_stock 
ON dbo.products (pcprod_ParentPrd, removed, stock) 
INCLUDE (description)