为什么'in'比SQLSelect中的'='快得多？

html5 • • 问答

此选择的执行时间约为 25 ~ 30 秒。

SELECT *
  FROM custinfo cs
 WHERE cs.idcust = (SELECT cust_id
                        FROM customers
                       WHERE id = 1230)

“ = ”的执行计划：

但是，如果我将 ' = ' 更改为 ' in '，那么它会变得更快，大约平均 0.040 ~ 0.060 秒。

SELECT *
      FROM custinfo cs
     WHERE cs.idcust in (SELECT cust_id
                            FROM customers
                           WHERE id = 1230)

' in ' 的执行计划：

并且有过这样的相反情况，其中 ' = ' 比 ' in ' 快。

有人知道为什么简单的语法更改会在性能和执行时间上产生如此大的差异吗？

什么时候“=”比“in”快，反之亦然？有什么条件可以在什么情况下使用？

  • 我正在为我的表使用 dblink。也许这就是影响我的查询的原因？
  • 好吧，伙计们，事情就是这样......现在我的两个查询都运行了大约 0.10 秒。所以现在我无法为我的查询在运行缓慢时找到执行计划。而且我完全不知道为什么我的查询性能在一天内发生了变化......就像，我只能猜测问题出在我们的服务器上，但是，为什么它只影响我的 1 个查询，而另一个正常运行？不过，这是我的执行计划：

' = '

' 在 '

回答

“IN”表示“此子查询中可能返回不止一行，请全部检查”，而“=”表示“子查询将只返回一行”，否则会出错。

有了这些信息，优化器会构建不同的查询计划。对于 "="-query，它首先执行子查询，然后过滤出 custInfo 表。

对于“IN”查询优化器执行连接操作，就像您编写了以下查询一样

SELECT *
  FROM custinfo cs
  JOIN customers c
    ON cs.idcust = c.cust_id
 WHERE c.id = 1230;

这就是执行时间不同的原因。根据您的数据选择性、索引、分区等，它可能需要更长的时间

更新。从您上传的执行计划中，我看到以下内容

  1. 对于“=”查询：
1.1. It competely scans the MT_OPERATION_OUT table (FULL TABLE SCAN), captures the result
1.2. Then it accesess another table on remote DB, presumably scans it too (REMOTE)
1.3. Filters data it got from remote.
  1. 对于“IN”查询：
2.1. It competely scans the MT_OPERATION_OUT table (FULL TABLE SCAN), captures the result
2.2. Sorts what it got on the previous step (SORT UNIQUE)
2.3. Then it accesess another table on remote DB, presumably scans it too (REMOTE)
2.4. Performs a join (NESTED LOOPS)

所以在我看来，由于某种原因，数据库需要更多时间来过滤来自远程数据库的数据，以便使用“嵌套循环”方法加入它。

以上是为什么'in'比SQLSelect中的'='快得多？的全部内容。
THE END
分享
二维码
< <上一篇
下一篇>>