大量数据的内连接和拆分答案

【问题标题】：Inner join and Split on large volume of data大量数据的内连接和拆分
【发布时间】：2012-10-17 01:14:29
【问题描述】：

我们正在处理大量数据（下面给出的行数）：

Table 1 : 708408568 rows  -- 708 million
Table 2 : 1416817136 rows -- 1.4 billion

Table 1 Schema:
----------------
ID -      Int PK
column2 - Int

Table 2 Schema
----------------
Table1ID - Int FK
SomeColumn - Int
SomeColumn - Int

Table1 有 PK1，它作为表 2 的 FK 服务。

索引详情：

Table1 : 
PK Clustered Index on Id
Non Clustered (Non Unique) on column2

Table 2 :
Table1ID (FK) Clustered Index

下面是需要执行的查询：

SELECT t1.[id]
      ,t1.[column2]
FROM  Table1 t1
inner join Table2 t2
    on s.id = cs.id
WHERE t1.[column2] in (select [id] from ConvertCsvToTable('1,2,3,4,5.......10000')) -- 10,000 Comma seperated Ids

总而言之，ID 上的内部连接应该由 PK 和 FK 上相同 ID 上的聚集索引处理。至于 column2 上的“巨大”Where 条件，我们有一个非聚集索引。

但是，对于 100 个 ID 的小子集，查询需要 4 分钟，我们需要传递 10,000 个 ID。

有没有更好的设计明智的方法可以做到这一点，或者表分区可能有帮助？

只是想获得一些方法来解决如何使用 Inner Join 和 Where IN 解决大量 Select。

注意：ConvertCsvToTable 是一个 Split 函数，已确定其性能最佳。

谢谢！

【问题讨论】：

WHERE EXISTS 通常会优于 IN 或者您可以将其发送到临时表，然后对其进行索引。
您能否提供一个使用 WHERE Exists 的示例查询，我无法获得预期的结果。

标签： sql-server-2008 tsql large-data-volumes

【解决方案1】：

这是我会尝试的：使用函数返回的结构创建一个临时表。确保将列 ID 设置为主键，以便优化器将其考虑在内...

CREATE TABLE #temp
(id    int          not null
    ...
,PRIMARY KEY (id) )

然后调用函数

insert into #temp exec ConvertCsvToTable('1,2,3,4,5.......10000')

然后使用查询中直接加入的临时表

SELECT t1.[id], t1.[column2]
FROM  Table1 t1, t2, #temp
where t1.id = t2.id
  and t1.[column2] = #temp.id

【讨论】：

【解决方案2】：

将条件带入连接
它使优化器有机会首先按 t1.[column2] 进行过滤
尝试不同的哈希提示

SELECT t1.[id], t1.[column2]
FROM  Table1 t1 with (nolock)
inner join Table2 t2 with (nolock)
   on s.id = cs.id
  and t1.[column2] in (select [id] from ConvertCsvToTable('1,2,3,4,5.......10000'))

您可能需要告诉它在 Column2 上使用该索引。
但要给它一个做正确事情的机会。
在你没有给它机会做正确事情的地方。

如果您使用#temp，请尝试
（并像鲁道夫所说的那样在温度上声明 PK +1）
这几乎会迫使它从小桌子开始
首先在 T2 上加入仍然可能会变得愚蠢，但我对此表示怀疑。

SELECT t1.[id], t1.[column2]
FROM #temp 
JOIN Table1 t1 with (nolock)
  on t1.[column2] = #temp.ID 
join Table2 t2 with (nolock)
   on t2.ID = t1.ID

【讨论】：