很多情况下，客户端在没有计划的情况下创建了列存储索引，不得不删除它们或重新创建查询和索引以最大程度地提高效率。
最近，一个大型的医疗技术组织雇用我来帮助进行全面的数据库性能运行状况检查，并且我与他们的高级DBA进行了非常有趣的对话，内容是“列存储索引显示实际行数为零”。
解释一下，我们将在此处的文章中使用相同的设置。设置完成后，让我们运行以下语句。
USE [AdventureWorks2017]
GO
-- Select Table with disable batch mode hint
SELECT ProductID, SUM(UnitPrice) SumUnitPrice, AVG(UnitPrice) AvgUnitPrice,
SUM(OrderQty) SumOrderQty, AVG(OrderQty) AvgOrderQty
FROM [dbo].[MySalesOrderDetail]
GROUP BY ProductID
ORDER BY ProductID
GO
现在让我们检查执行计划。当您看到执行计划时，它表示Columnstore Index已处理零行。请仔细查看此处显示的图像。
当您检查Columnstore Index扫描运算符时，它表示已处理了零行，紧接着还有一个哈希匹配运算符，则表示正在处理266页。当我们看到零行传给任何运算符并返回266个运算符时，这可能会非常令人困惑。客户也对此细节感到非常困惑，并问“实际数字”是怎么回事。
答案很简单。
ColumnStore –实际行数为零
SQL Server执行计划有很多限制，最大的限制之一是与应显示的内容相比，它的资源很少。当前格式的SQL Server执行计划有很多限制。
如果您熟悉列存储索引，就会知道它不会以我们已知的“ 传统方式 ” 读取行。实际上，由于列存储的体系结构非常不同，因此它会读取列段。由于它不读取传统行（通过逻辑读取和物理读取），因此在此处显示零值。但是，如果通过启用统计信息IO查看消息，则会注意到两个不同的部分。一个用于行存储，另一个用于列存储。
现在，当将细分数据传递给批处理匹配运算符时，它仍必须处理从细分中获取（提取）的传统行，并开始一起处理它们。
此外，如果您查看Columnstore索引运算符的详细信息，虽然它说“ 实际行数”为零，但它会将行处理为“本地聚合行的实际数”。当您将两个数字相加时，您将找到要处理的总行数。
SSMS预期未来会有所改善
希望这种解释可以帮助您了解使用SSMS和ColumnStore Index时实际发生的情况。希望在SSMS的未来版本中，只要有一个列存储索引操作显示，而不是零它会显示总的行的实际数量和本地集合行的实际数量。
