主要是和普通的索引进行对比：
/********************
准备数据
******************/
select * into ColumnStoreTest from northwind..orders
declare @i int
set @i = 12
while(@i > 0)
begin
insert into ColumnStoreTest
select * from ColumnStoreTest
union all
select * from ColumnStoreTest
set @i = @i-1
end
--顺带提一下，因为 into 会把 identity 也写进去，为了方便 我就把ColumnStoreTest 的 identity 给散掉了
@i 用12 可能数据量有点多，可以自己调整
/**************************
创建columnstrore index
************************/
create index idx_CustomerID on ColumnStoreTest(CustomerID,Freight)
create columnstore index csidx_CustomerID on ColumnStoreTest(CustomerID,Freight)
这个是使用第一个索引测试产生的结果
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒，占用时间 = 5 毫秒。
(89 行受影响)
表 'ColumnStoreTest'。扫描计数 5，逻辑读取 7352 次，物理读取 0 次，预读 32 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
(6 行受影响)
(1 行受影响)
SQL Server 执行时间:
CPU 时间 = 1529 毫秒，占用时间 = 544 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
执行计划也没什么特别的就是 普通的索引扫描
select CustomerID,sum(Freight) from ColumnStoreTest group by CustomerID
|--Compute Scalar(DEFINE:([Expr1004]=CASE WHEN [globalagg1006]=(0) THEN NULL ELSE [globalagg1008] END))
|--Stream Aggregate(GROUP BY:([Northwind].[dbo].[ColumnStoreTest].[CustomerID]) DEFINE:([globalagg1006]=SUM([partialagg1005]), [globalagg1008]=SUM([partialagg1007])))
|--Parallelism(Gather Streams, ORDER BY:([Northwind].[dbo].[ColumnStoreTest].[CustomerID] ASC))
|--Stream Aggregate(GROUP BY:([Northwind].[dbo].[ColumnStoreTest].[CustomerID]) DEFINE:([partialagg1005]=COUNT_BIG([Northwind].[dbo].[ColumnStoreTest].[Freight]), [partialagg1007]=SUM([Northwind].[dbo].[ColumnStoreTest].[Freight])))
|--Index Scan(OBJECT:([Northwind].[dbo].[ColumnStoreTest].[idx_CustomerID]), ORDERED FORWARD)
SQL Server 分析和编译时间:
CPU 时间 = 16 毫秒，占用时间 = 93 毫秒。
(89 行受影响)
表 'ColumnStoreTest'。扫描计数 4，逻辑读取 34 次，物理读取 2 次，预读 18 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
(7 行受影响)
(1 行受影响)
SQL Server 执行时间:
CPU 时间 = 63 毫秒，占用时间 = 281 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
select CustomerID,sum(Freight) from ColumnStoreTest group by CustomerID
|--Compute Scalar(DEFINE:([Expr1004]=CASE WHEN [globalagg1006]=(0) THEN NULL ELSE [globalagg1008] END))
|--Stream Aggregate(GROUP BY:([Northwind].[dbo].[ColumnStoreTest].[CustomerID]) DEFINE:([globalagg1006]=SUM([partialagg1005]), [globalagg1008]=SUM([partialagg1007])))
|--Sort(ORDER BY:([Northwind].[dbo].[ColumnStoreTest].[CustomerID] ASC))
|--Parallelism(Gather Streams)
|--Hash Match(Partial Aggregate, HASH:([Northwind].[dbo].[ColumnStoreTest].[CustomerID]), RESIDUAL:([Northwind].[dbo].[ColumnStoreTest].[CustomerID] = [Northwind].[dbo].[ColumnStoreTest].[CustomerID]) DEFINE:([partialagg1005]=COUNT_BIG([Northwind].[dbo].[ColumnStoreTest].[Freight]), [partialagg1007]=SUM([Northwind].[dbo].[ColumnStoreTest].[Freight])))
|--Index Scan(OBJECT:([Northwind].[dbo].[ColumnStoreTest].[csidx_CustomerID]))
可以从这2个结果中看出，逻辑读的数量columnstore index 明显比 普通索引的少，这也就是 columnstore 索引的优势
但是如果是普通的select * from where 这类语句那columnstore index 还有优势嘛？
是不是和 oracle的bitmapindex 一样在 or 语句中 也很有优势呢？
在columnstore index 状况下的执行计划没有一点优势：
因为大家对非聚集索引比较了解，我也就不发非聚集索引在这种状况下的执行计划了。
select * from ColumnStoreTest where customerid = 'VINET' or customerid = 'TOMSP'
|--Parallelism(Gather Streams)
|--Table Scan(OBJECT:([Northwind].[dbo].[ColumnStoreTest]), WHERE:([Northwind].[dbo].[ColumnStoreTest].[CustomerID]=N'TOMSP' OR [Northwind].[dbo].[ColumnStoreTest].[CustomerID]=N'VINET'))
都已经是表扫描了其实也没什么好说的了。
上面的例子是再选择性低的情况下的执行计划。
那么如果选择性高又会怎么样呢？
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 16 毫秒，占用时间 = 28 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
(1 行受影响)
表 'ColumnStoreTest'。扫描计数 1，逻辑读取 12 次，物理读取 0 次，预读 2 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
(4 行受影响)
(1 行受影响)
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 86 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
SELECT * FROM [ColumnStoreTest] WHERE [orderid]=@1
|--Nested Loops(Inner Join, OUTER REFERENCES:([Bmk1000]))
|--Index Scan(OBJECT:([Northwind].[dbo].[ColumnStoreTest].[csidx_orderID]), WHERE:([Northwind].[dbo].[ColumnStoreTest].[OrderID]=(10248)))
|--RID Lookup(OBJECT:([Northwind].[dbo].[ColumnStoreTest]), SEEK:([Bmk1000]=[Bmk1000]) LOOKUP ORDERED FORWARD)
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒，占用时间 = 9 毫秒。
SQL Server 分析和编译时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
(1 行受影响)
表 'ColumnStoreTest'。扫描计数 1，逻辑读取 3 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
(4 行受影响)
(1 行受影响)
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 92 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
SQL Server 执行时间:
CPU 时间 = 0 毫秒，占用时间 = 0 毫秒。
SELECT * FROM [ColumnStoreTest] WHERE [orderid]=@1
|--Nested Loops(Inner Join, OUTER REFERENCES:([Bmk1000]))
|--Index Seek(OBJECT:([Northwind].[dbo].[ColumnStoreTest].[idx_orderid]), SEEK:([Northwind].[dbo].[ColumnStoreTest].[OrderID]=(10248)) ORDERED FORWARD)
|--RID Lookup(OBJECT:([Northwind].[dbo].[ColumnStoreTest]), SEEK:([Bmk1000]=[Bmk1000]) LOOKUP ORDERED FORWARD)
csidx_orderid 是columnstore index
idx_orderid 是非聚集索引
仔细比较逻辑读，就能看出，在高选择性，传统索引是比较又优势的。
关于or，理论上来说是columnstore index 比非聚集索引又优势。
因为我相信，columnstore index 是和bitmap index 相同原理的。
如果对bitmap index 不太了解可以参考：《expert oracle database architecture》中的相关章节
本文转自 Fanr_Zh 博客园博客，原文链接：http://www.cnblogs.com/Amaranthus/archive/2011/11/28/2266165.html，如需转载请自行联系原作者
