SQL Server 列存储索引性能总结（7）——导入数据到列存储索引的Delta Store

接上文：SQL Server 列存储索引性能总结（6）——列存储等待信息，这一篇还是本人工作中的难点，列存储导入速度的问题，我们都知道有索引的表导入肯定比堆表慢，可是究竟为什么呢？对于列存储来说，很可能就是Delta Store的原因。

  列存储索引有推荐的最佳导入行数，过小会导致数据先进入Delta Store（行组，row group），这个是行存储的B 树结构，然后通过Tuple Mover对数据进行编码和压缩最终成为片段（segment），这时候才能说进入了真正的列存储索引中，才能真正发回去列存储索引的优势。
  在我目前的项目中，导入数据是个头痛的事情，数据量不是非常大，但是表的列很多，4~500列。导致即使是纯粹导进堆表，最高可能也就50000行每秒，更别说聚集列存储索引，而且加上公司使用固定工具带来的不合理的导入方式。
  从外部导入数据到数据库时，不管是导入列存储还是堆表，最好的方式还是使用各种大容量导入工具比如BCP/Bulk insert API等，可以使得数据能够直接进入片段而不用先到Delta store然后再进行转换。
  当然，在现实世界中很多时候没法真的尽如人意。言归正传，在没有办法使用Bulk insert的时候，到底发生了什么？下面创建一个单列的表，然后插入6700万数据用于创建足够的行组。这个数不是随便选的，后面会看到理由。

环境准备

本系列的脚本由于有时效性，所以建议先看完再执行，需要连续执行。
  首先初始化一批数据，这个可以在TempDB里面做：

--创建表
create table dbo.Test(id int not null );
--创建聚集列存储索引
create clustered columnstore index CCI on dbo.Test;
--导入刚好够一个片段的数据，也就是1048576行
declare @i as int;
set @i = 1;

begin tran