Sql 列存储索引和nvarchar（最大值）

我计划将JSON文档存储在SQL Server 2017中集群列存储索引表的

nvarchar（max）

列中

我从供应商（Microsoft）那里得到了一些相互矛盾的信息，无论这是否是一个好主意：

在以下情况下，不要使用聚集列存储索引：

• 该表需要

  varchar（max）

  、

  nvarchar（max）

  或

  varbinary（max）

  数据类型。或者，设计columnstore索引，使其不包含这些列

而微软的其他几篇博文则相反：

在后一篇文章中甚至有很好的测试，但是第一篇“不要使用…”没有任何东西来支持该语句

---

有没有人有过可能出错的经验？或者有人在数百万行的生产中使用这种功能吗？

列存储索引的限制和限制
在非聚集列存储索引中不能包含

nvarchar（max）

、

varchar（max）

和

varbinary（max）

类型的大型对象（LOB）列。只有群集columnstore索引支持LOB类型，从SQL Server 2017（14.x）版本开始，在高级层、标准层（S3及以上）和所有VCore产品层配置Azure SQL数据库。注意，以前的版本不支持集群和非集群列存储索引中的LOB类型

---

在columnstore中存储JSON的实验对我来说似乎很可疑。关键的是，当只使用常规表压缩时，它无法测试加速比（

DATA\u compression=PAGE

）。仅使用columnstore压缩文本数据对我来说似乎是一种巨大的浪费——columnstore仍然会尝试对行的内容进行索引和分段，这是毫无用处的，而且纯粹是开销。批处理模式的处理确实增加了加速，但你可以有一个带有页面压缩的表，并从中挤出批处理模式（2019年自动，在早期版本中有一个hack）。一个好问题是，你是否计划实际索引你的文档——也就是，如果要根据JSON文档中的某些固定部分查找它们。您可以使用计算列来编辑，但ColumnStore不允许使用计算列（更不用说索引了），所以这是一个很大的限制。尽管列存储速度很快，但如果没有索引，您仍然会一直扫描所有数据。CCI实验没有考虑的另一个关键问题是更新/删除。如果您只想附加JSON数据，那么一个只有一列的表就可以了。否则，您将不得不考虑修改事务的数量（和性质），因为在columnstore上这些东西比在rowstore上更昂贵。正如我所说，我还将测试一个表，其形式为

CREATE table T（ID BIGINT IDENTITY，[data]NVARCHAR（MAX），CONSTRAINT PK\T\u ID主键集群（ID）使用（DATA_COMPRESSION=PAGE），索引IX_T_Dummy_CS非聚集列存储（ID），其中（ID为NULL））

。这是一个带有页面压缩的常规行存储，它使用一个虚拟列存储索引“免费”从批处理模式中获益，从而保留了使用计算列为JSON索引的选项。不过，我还没有测试过这篇文章的性能特征（当然，它们会随着场景的不同而有所不同）。如果作者针对您通常会遇到的不同场景和其他压缩选项在文章中提到显而易见的问题，我会认为这是一篇更好的文章，但作为一个整体“以下是如何在不改变任何东西的情况下在新版本的SQL Server中实现更快的速度”我想这是一个好消息，它很好地完成了它的工作。：-P在columnstores中存储

NVARCHAR（MAX）

列有一些合理的问题需要解决，而“这总是不好的”和“这只是一个好主意的时期”都没有真正涵盖它。