8

我正在尝试将两个相对简单的表连接在一起，但我的查询遇到了严重的挂起。我不知道为什么，但我认为这可能与“之间”功能有关。我的第一个表看起来像这样（还有很多其他列，但这将是我要提取的唯一列）：


RowNumber
1
2
3
4
5
6
7
8

我的第二个表将我的行“分组”为“块”，并具有以下架构：


BlockID     RowNumberStart     RowNumberStop
1           1                  3
2           4                  7
3           8                  8

我希望得到的结果是将 RowNumber 与 BlockID 链接起来，如下所示，与第一个表的行数相同。所以结果看起来像这样：


RowNumber   BlockID           
1           1
2           1
3           1
4           2
5           2
6           2
7           2 
8           3

为了得到它，我使用了以下查询，将结果写入临时表：


select A.RowNumber, B.BlockID
into   TEMP_TABLE
from   TABLE_1 A left join TABLE_2 B
on     A.RowNumber between B.RowNumberStart and B.RowNumberStop

TABLE_1 和 TABLE_2 实际上是非常大的表。表 1 大约有 122M 行，而 TABLE_2 大约有 65M 行。在 TABLE_1 中，RowNumber 被定义为“bigint”，而在 TABLE_2 中，BlockID、RowNumberStart 和 RowNumberStop 都被定义为“int”。不确定这会有所不同，但也只是想包含该信息。

查询现在已经挂了八个小时。对这种类型和数据量的类似查询不会花费这么长时间。所以我想知道它是否可能是挂起这个查询的'between'语句。

绝对会欢迎有关如何提高效率的任何建议。

4

2 回答 2

9

BETWEEN 只是 的简写：

select A.RowNumber, B.BlockID
into   TEMP_TABLE
from   TABLE_1 A left join TABLE_2 B
on     A.RowNumber >= B.RowNumberStart AND A.RowNumber <= B.RowNumberStop

如果执行计划从 B 到 A（但左连接实际上表明它必须从 A 到 B），那么我假设 TABLE_1 在 RowNumber 上被索引（这应该涵盖在这个查询中）。如果它只有 RowNumber 上的聚集索引并且表很宽，我建议只在 RowNumber 上使用非聚集索引，因为这样每页可以容纳更多的行。

否则，您希望在 RowNumberStart DESC 或 RowNumberStop ASC 上的 TABLE_2 上建立索引，因为对于给定的 A，您需要 RowNumberStart 上的 DESC 才能匹配。

我认为您可能希望将您的加入更改为 INNER JOIN，您的加入标准的设置方式。（您是否会立即获得 TABLE_1 ？）

如果您查看您的执行计划，您应该会获得更多关于为什么性能可能不好的线索，但是在寻找 TABLE_1 时可能没有使用停止条件。

不幸的是，SQLMenace 关于 的回答SELECT INTO已被删除。我对此的评论是：@MartinSELECT INTO的性能不像以前那么糟糕，但我仍然建议CREATE TABLE对大多数生产使用一个，因为它SELECT INTO会推断类型和 NULLability。如果您验证它正在做您认为它正在做的事情，这很好，但是创建了一个超长varchar或decimal具有非常奇怪精度的列不仅会导致奇怪的表，而且还会导致性能问题（尤其是当您忘记 LEFT 或其他内容时，对于一些大的 varchars）。我认为这有助于明确您对表格的期望。通常我会使用 WHERE 0 = 1 选择 INTO 并检查架构，然后使用我的调整编写脚本（例如添加 IDENTITY 或添加带有默认时间戳的列）。

于 2011-04-07T14:28:41.873 回答
1

你有一个主要问题：你想一次显示太多的数据量。您真的确定要一次处理表 1 中所有122M 行的结果吗？你真的需要那个吗？

于 2011-04-07T14:24:14.033 回答