Question

同事在使用Microsoft SQL Server的企业中工作。他们的团队创建了每天执行的存储过程，以创建数据摘录。基础表很大（有些表有数十亿行），因此大多数存储过程的设计方式是，它们首先仅将这些大表的相关行提取到临时表中，然后将临时表相互连接，并与其他较小的表连接表以创建最终摘录。与此类似：

SELECT COL1, COL2, COL3
INTO #TABLE1
FROM HUGETABLE1
WHERE COL4 IN ('foo', 'bar');

SELECT COL1, COL102, COL103
INTO #TABLE2
FROM HUGETABLE2
WHERE COL14 = 'blah';

SELECT COL1, COL103, COL306
FROM #TABLE1 AS T1
JOIN #TABLE2 AS T2
ON T1.COL1 = T2.COL1
LEFT JOIN SMALLTABLE AS ST
ON T1.COL3 = ST.COL3
ORDER BY T1.COL1;

通常，临时表在创建后不会被修改（因此，不会再进行后续的ALTER，UPDATE或INSERT操作）。出于讨论的目的，我们假设临时表仅在以后使用一次（因此只有一个SELECT查询将依赖它们）。

这里是问题：在创建这些临时表之后，再将它们用于后续查询之前，对这些临时表进行索引是个好主意吗？

我的同事认为，创建索引将使联接和排序操作更快。但是，我相信总的时间会更长，因为创建索引需要时间。换句话说，我假设除了边缘情况（例如临时表本身非常大，或者最终的SELECT查询非常复杂）之外，SQL Server将使用临时表上的统计信息来优化最终查询，这样做可以有效地索引临时表。

换句话说，我习惯于认为只有在您知道经常使用表的情况下，创建索引才有用。存储过程完成后删除的一次性使用的临时表不值得索引。

我们都不了解SQL Server优化器，以了解我们是对是错。您能否帮助我们更好地了解我们的哪个假设更接近真实？

Answer 1

如果每天要提取数十亿行数据，我建议您使用登台表而不是临时表。这将使用tempdb将您的数据提取与其他资源隔离。

这里是问题：在创建这些临时表之后，再将它们用于后续查询之前，对这些临时表进行索引是个好主意吗？

将数据加载到临时表后创建索引。 这将消除碎片并创建统计信息。

优化器将使用统计信息生成最佳计划。因此，如果您没有统计信息，则可能会极大地影响您的查询性能，尤其是对于大型数据集。

下面的示例查询临时表中索引创建的前后比较：

/* Create index after data load into temp table -- stats is created */
CREATE TABLE #temp ( [text] varchar(50), [num] int);
INSERT INTO #temp([text], [num]) VALUES ('aaa', 1), ('bbb', 2) , ('ccc',3);
CREATE UNIQUE CLUSTERED INDEX [IX_num] ON #temp (num);
DBCC SHOW_STATISTICS ('tempdb..#temp', 'IX_num');

/* Create index before data load into temp table -- stats is not created */
CREATE TABLE #temp_nostats ( [text] varchar(50), [num] int);
CREATE UNIQUE CLUSTERED INDEX [IX_num] ON #temp_nostats (num);
INSERT INTO #temp_nostats([text], [num]) VALUES ('aaa', 1), ('bbb', 2) , ('ccc',3);
DBCC SHOW_STATISTICS ('tempdb..#temp_nostats', 'IX_num');

您需要测试索引是否对您有帮助。您需要平衡可以拥有的索引数量，因为如果索引过多，它也会影响性能。

Answer 2

您的朋友可能是正确的，因为即使在单个查询中使用表，也不会看到查询（即使我们这样做，我们仍然对执行计划的样子不太了解。），我们不知道SQL Server需要多少次才能在每个表的各个列中查找数据以进行联接，排序等。

但是，直到它实际上完成了两种方法并测量和比较了结果，我们才能确定。

索引一次性临时表

2 个答案: