理解 SQL 查询为什么花费时间过长

Question

我有一个相当大的SQL查询语句。以下是我遇到问题的简化版本。

SELECT * 
FROM dbo.MyTransactionDetails TDTL
    JOIN dbo.MyTransactions TRANS
       on TDTL.ID = TRANS.ID
    JOIN dbo.Customer CUST
       on TRANS.CustID = CUST.CustID
WHERE TDTL.DetailPostTime > CONVERT(datetime, '2015-05-04 10:25:53', 120) 
    AND TDTL.DetailPostTime < CONVERT(datetime, '2015-05-04 19:25:53', 120) 

MyTransactionDetails表包含约700万行，而MyTransactions表只有约30万行。

以上查询大约需要10分钟的运行时间，这很疯狂。所有索引都已经重新建立过，并且所有ID列上都有索引。

如果我在WHERE子句中添加以下行，查询时间将会缩短到约1秒钟。

AND TRANS.TransBeginTime > CONVERT(datetime, '2015-05-05 10:25:53', 120) 
    AND TRANS.TransBeginTime < CONVERT(datetime, '2015-05-04 19:25:53', 120) 

我知道数据库的内容，TransBeginTime与DetailPostTime几乎相同，因此这些额外的where子句不应该过滤比JOIN更多的内容。

为什么这些附加条件会快很多呢？

问题在于，我不能使用TransBeginTime进行筛选，因为不能保证交易明细将在同一日期发布。

编辑：我还应该补充的是，执行计划显示50％的时间被MyTransactionDetails占用。

- CathalMF

---

糟糕，我错过了。有类似于EXPLAIN的东西吗？ - Dan

@CathalMF，那就只有等待10分钟的方法了。 - Giorgi Nakeuri

@CathalMF，因为TransBeginTime上有索引。 - Giorgi Nakeuri

@GiorgiNakeuri 恭喜，就是这样。TransBeginTime 上有一个索引。 - CathalMF

@HingeSight 这不正确。JOIN 和 INNER JOIN 是相同的。 - CathalMF

Answer 1

计划中显示的百分比（估计值和实际值）是基于假设估计行数正确的估计值。在糟糕的情况下，百分比可能完全错误，甚至1%实际上可能是95%。

要弄清楚实际发生了什么，请打开“statistics io”。这将告诉您每个表的逻辑I/O计数 - 并且将其减少通常意味着时间也会减少。

您还可以查看实际计划，有很多因素会导致缓慢，例如扫描、排序、键查找、卷等。如果同时包括统计I/O和执行计划（最好是实际的xml，而不仅仅是图片），那么更容易弄清楚出了什么问题。

- James Z