此文将讨论在处理SQL Server中的ColumnStore索引时以FAQ格式进行故障排除的情况。结合使用跟踪标志，查询提示，性能计数器，各种文章中讨论的扩展事件来收集相关数据并解决问题。
有时看到有人将ColumnStore用作解决升级后的SQL Server性能问题的灵丹妙药。常见的问题是：创建ColumnStore索引并不能达到预期的效果。什么地方出了错？我们从哪里开始？如果您问我，那么诊断工作可能包括询问以下一些问题：
优化器是否使用ColumnStore索引？如果没有，为什么不呢？
用户可以通过查看SHOWPLAN来确定查询计划中是否使用了ColumnStore索引。新的属性Storage可以具有两个值之一，即行存储或列存储。Storage = ColumnStore指示在查询计划中使用了ColumnStore。
查询优化器会根据成本决定是否将ColumnStore用作给定查询的访问方法。要了解ColumnStore的使用，存在一些限制：
- 通过使用表提示（例如，FROM t WITH（INDEX（myColumnStoreindex）），可以强制（或避免）使用ColumnStore索引。
- ColumnStore索引不支持SEEK。如果期望查询返回一小部分行，则优化器不太可能选择ColumnStore索引。
- 如果使用表提示FORCESEEK，则优化器将不考虑ColumnStore索引。
- 如果将使用ColumnStore索引的提示与FORCESEEK结合使用，则优化器将无法生成计划，查询将失败并返回错误消息。
- 如果使用SET FORCEPLAN或FORCE ORDER提示，则优化器将接受该提示。如果优化程序否则将starjoin优化与starjoin位图一起使用，则使用提示可能会导致性能比没有提示的情况差。可以使用批处理，但不能保证。
- 查询提示IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX将阻止在每个查询的基础上使用任何ColumnStore索引。
- 如果打开TF 9453，则查询优化器将不会为任何查询选择ColumnStore索引（并且将不使用批处理模式处理）。
- 如果打开TF 9462，则查询优化器将不会选择ColumnStore索引，除非查询提示明确指定了ColumnStore索引。
- 如果TF 9453和TF 9462都打开，则查询优化器将不会选择ColumnStore索引。如果添加了查询提示以指定ColumnStore索引，则查询将失败，并显示错误消息8622，该消息指出查询处理器由于查询中定义的提示而无法生成查询计划。
接下来的问题到 SK会，是在查询中使用批处理执行？
用户可以通过查看SHOWPLAN来确定是否对特定操作员使用了批处理。EstimatedExecutionMode可以具有行或批两个值之一。
EstimatedExecutionMode = batch表示在查询计划中选择了批处理。ActualExecutionMode也可以具有两个值之一，即row或batch。如果EstimatedExecutionMode =批处理，而ActualExecutionMode =行，则在运行时无法以批处理模式执行查询，这表明没有足够的内存可用于批处理（或没有足够的线程可用于并行执行）。EstimatedExecutionMode = row和ActualExecutionMode = batch的组合将永远不会发生。对于复杂的查询，某些部分可能以批处理模式执行，而某些部分可能以行模式执行。
接下来的分析是，ColumnStore索引是否为我的数据提供了良好的压缩？
数据可以压缩的程度高度依赖于数据。具有大量唯一字符串的列不能像具有许多重复字符串值的列那样被压缩。同样，覆盖较大范围值的数字数据不能像覆盖较大范围值的数字数据那样高效编码。对于给定的数据集，在ColumnStore索引中包含较少的列通常将导致对索引中的列进行更好的压缩，并且由于数据较少（列较少）而导致索引较小。但是，通常建议将表中的所有列都包含在ColumnStore索引中，以确保所有查询都将从索引的使用中受益。
最后一个问题是查询优化器是否找到了一个好的计划？
查询计划照常显示在Showplan中。可以通过查看访问方法（事实表是否使用ColumnStore索引？），是否存在一个或多个“批处理哈希表构建”运算符以及ActualExecutionMode = Batch来确定是否将批处理/列存储计划用于星型联接查询。
