为什么子查询和连接这么慢

Question

我需要从 BUNDLES 表中选择具有几个 SAP_STATE_ID 值之一的行。这些值取决于是否应该导出相应的 SAP 状态。

这个查询运行得非常快（在 SAP_STATE_ID 字段上有索引） -

SELECT b.* FROM BUNDLES b WHERE b.SAP_STATE_ID IN (2,3,5,6)

但是...我想动态获取 ID 列表，如下所示：

SELECT b.* FROM BUNDLES b 
WHERE b.SAP_STATE_ID IN 
(SELECT s.SAP_STATE_ID FROM SAP_STATES s WHERE s.EXPORT_TO_SAP = 1)

哎呀，这个查询突然花费了太多时间。我希望 SQL 服务器首先运行子查询（它不依赖于主查询中的任何内容），然后像我的第一个示例一样运行整个事情。我试图重写它以使用连接而不是子查询：

SELECT b.* FROM BUNDLES b 
JOIN SAP_STATES s ON (s.SAP_STATE_ID = b.SAP_STATE_ID) 
WHERE s.EXPORT_TO_SAP = 1

但它的性能同样很差。似乎它正在为 BUNDLES 表的每一行或类似的东西运行子查询。我在阅读执行计划方面不是很熟练，但我试过了。它说 81% 的成本是用于扫描 BUNDLES 的主键索引（我不知道为什么要这样做，有 BUNDLE_ID 字段定义为 PRIMARY KEY，但它根本没有出现在查询中...... )

有没有人解释一下为什么 SQL Server 如此“愚蠢”？有没有办法以良好的性能实现我想要的，但无需提供 SAP_STATE_ID 的静态列表？

表和相关索引的脚本 - http://mab.to/xbYiI0wKj

子查询版本的执行计划 - http://mab.to/8Qh6gpdYZ

带有连接的版本的查询计划 - http://mab.to/YCqeGCUbr

（由于某种原因，这两个计划看起来相同，并且都建议创建 BUNDLES.SAP_STATE_ID 索引，该索引已经存在）

Answer 1

我很确定你的统计数据在表格上是关闭的。如果您想让它快速运行，我会将查询编写为：

SELECT b.*
  FROM SAP_STATES s 
 INNER LOOP JOIN BUNDLES b 
    ON s.SAP_STATE_ID = b.SAP_STATE_ID
 WHERE s.EXPORT_TO_SAP = 1

这会强制一个嵌套循环加入SAP_STATES，它会过滤BUNDLES

Answer 2

当您使用表（临时表或物理表）时，SQL 引擎会针对它构建统计信息，因此对其中的行数有一个非常清晰的想法，以及哪种是它的最佳执行方法。另一方面，计算表（子查询）没有针对它的统计信息。

因此，虽然人类推断其中的行数似乎很简单，但“愚蠢”的 SQL 引擎并没有意识到这一切。现在，来到查询中，WHERE s.EXPORT_TO_SAP = 1 子句在这里产生了巨大的变化。聚集索引是根据 SAP_STATE_ID 排序和构建的，但要额外检查 WHERE 子句，它别无选择，只能扫描整个表（在最终数据集中）！我敢打赌，如果不是聚集索引，而是 SAP_STATE_ID 列上有一个覆盖 EXPORT_TO_SAP 字段的非聚集覆盖索引，它可能已经成功了。由于聚集索引扫描通常不利于性能，我建议您采用以下方法：

SELECT s.SAP_STATE_ID 
into #Sap_State
FROM SAP_STATES s WHERE s.EXPORT_TO_SAP = 1

SELECT b.* FROM BUNDLES b 
join #Sap_State a on a.sap_state_id = b.sap_state_id

Answer 3

由于某些原因导致 mab.to 出现问题，

我建议确保以下内容

table        index
sap_states   (export_to_sap, sap_state_id )
bundles      (sap_state_id)

select
      b.*
   from 
      sap_states ss
         join bundles b
            on ss.sap_state_id = b.sap_state_id
   where 
      ss.export_to_sap = 1