使用群集的列存储索引在SQL Server中将大表联接到小表需要太长时间

Question

尝试连接2个表时，我遇到了非常慢的性能：一个表有39M行，其他表有10k（35秒）。 它在非常不错的服务器Azure SQL Premium实例上运行

select m39.* 
from [Table_With_39M_Rows] m39 
inner join [Table_With_10K_Rows] k10 on m39.[Id] = k10.[Id]

甚至一个count(*)需要大约10秒

select count(*) 
from [Table_With_39M_Rows] m39 
inner join [Table_With_10K_Rows] k10 on m39.[Id] = k10.[Id]

以下是表格的详细信息：

表[Table_With_39M_Rows]大约有3,900万行（50列），具有聚集的列存储索引：

 CREATE CLUSTERED COLUMNSTORE INDEX CCI_Table_With_39M_Rows ON Table_With_39M_Rows CREATE UNIQUE NONCLUSTERED UNCI_Table_With_39M_Rows_Id (Id ASC)

表[Table_With_10K_Rows]大约有1万行（50列），并且Id作为主键

 ALTER TABLE Table_With_10K_Rows ADD CONSTRAINT PK_Table_With_10K_Rows PRIMARY KEY CLUSTERED([Id] ASC)

群集的ColumnsStore索引扫描占用99％的速度，并降低所有速度。

如何优化此特定联接？ 我应该采用什么索引策略？

Answer 1

如果行组消除有效 （您可以考虑跳过不满足谓词的整个行段），并且查询本质上是分析的，则聚集的列存储索引会很有用。

要检查是否发生了段消除，可以使用以下查询

以下是我所拥有的查询的示例演示（因为我们没有您的测试数据），这可能有助于您了解更多

查询：

select s.* from sales s
join
numbers n
on n.number=s.id

Numbers表仅具有65356行，而sales表具有超过300万行。每个段只能具有100万行。如果您可以观察statistics IO的输出，SQLSERVER将读取2个段（200万行），并跳过2个段，这不是很好，我希望仅读取一个段，而跳过其余三个段。但是如下所示读取了2个段

Table 'sales'. Segment reads 2, segment skipped 2.

发生这种情况是因为您可能已经从堆中创建了集群列存储，所以请尝试以下操作

删除您现有的集群列存储索引，在我的情况下是

drop index nci on sales

现在尝试先创建聚簇索引，然后再创建聚簇列存储，这有助于sqlserver将行按顺序插入到聚簇列存储索引中。.您可能还希望使用maxdop 1以避免并行和无序行

create clustered index  nci on sales(id)

create clustered columnstore index nci  on sales
with (drop_existing=on,maxdop =1)

如果现在运行查询，则可以看到细分消除并且查询速度很快

Table 'sales'. Segment reads 1, segment skipped 2.

参考资料和进一步阅读：
https://www.sqlpassion.at/archive/2017/01/30/columnstore-segment-elimination/ https://blogs.msdn.microsoft.com/sqlserverstorageengine/2016/07 / 17 / columnstore-index-how-他们会从传统的btree索引在行存储表中延迟/
https://blogs.msdn.microsoft.com/sql_server_team/columnstore-index-performance-rowgroup-elimination/

Answer 2

我建议您在使用[]时保持一致。

外键的ID不是一个好名字。

描述的列存储索引

列存储索引为使用全表扫描的查询提供了高性能，并且不适用于寻求数据，搜索特定值的查询。

仅仅因为您需要columnstore用于其他目的并不能使其成为一个很好的应用程序。

尝试在[Table_With_39M_Rows]上使用常规非聚集索引。[ID]