我还没有找到一篇文章能够充分描述ASE中文本数据的存储，特别是在高效存储数据方面。所以，这是我最近处理的一个例子，在收到关于ASE中相对少量的文本占用了大量空间的投诉之后。 在本例中，我们将使用一个7.81GB的表，将其减少到798MB，然后将其减少到487MB。这些步骤说明了如何减少文本数据的存储。 LOB（文本和图像）数据压缩没有很好的文档记录。在ASE中实际上有两个可用的东西。第一件事叫做行存储。第二件事叫做数据压缩，我称之为行内存储的"增强"。所有这些都没有记录在案。这两个特性在过去几年中被添加到ASE中。要弄清这一点，您必须搜索9000页的ASE文档。行内存储

行内存储

此功能将LOB数据从索引页移动到数据页。默认情况下，LOB数据存储在称为行外存储的索引页中，每个索引页一行。因此，如果您有一个包含文本数据的1000000行表，那么您将有1000000个文本数据索引页。即使实际文本是1字节，也会在磁盘上为它保留一个完整的索引页。这是对磁盘空间的难以置信的浪费。相比之下，行内存储会将尽可能多的数据打包到数据页中。 我觉得称之为"索引"页面有点奇怪。它实际上是一个"行外LOB页"。但我怀疑ASE工程师可能已经用"数据"和"索引"两种页面对数据服务器进行了编码，也许添加第三种页面可能是一项艰巨的任务。也许 吧。 我们的数据服务器页面大小是8192字节。对于1000000行，这将是8GB左右。下面是一个例子。我添加了额外的证据来验证磁盘空间，因为我无法识别效果：

好的，一个表是用文本数据类型创建的，我们已经加载了1000000行。让我们看看"before"的大小。

在最后一个查询中，您可以清楚地看到空间的使用情况。文本数据使用7.812GB的存储空间！几乎没有那么多的文本数据。实际上，jsonMessage文本的平均长度是755字节。实际上，1000000行数据的大小应该在755MB左右。好的，让我们把文本数据移到行内存储。为此，必须估计行内LOB列的字节数。范围是0到数据库的逻辑页大小。

由于开销，行大小实际上是8108字节。减去messageId（4字节），bi大数据，jsonMessage可以是8108-4=8104。好吧，让它变成8000平。这是一个行内数据页可以容纳的json文本的最大数量。如果json文本超过8000字节，大数据下，它将保留在行外索引页存储中。如果json文本很小，那么在分配下一个数据页之前，一堆json文本可以放入一个数据页，最多8000字节。 现在我们将修改列以具有行内存储，云服务器免费，并将数据从行外迁移到行内。如果您从下面的alter table命令中得到警告，则降低数值。

对表执行sp\u帮助，将输出的length列中的数据类型长度相加，然后从8108中减去。也就是在计算完所有列之后，一个数据页上有多少字节是空闲的。

sp\u spaceusage查询显示798MB。sp_helpdb查询显示我们释放了6.9GB（（5120-165）+（10240-7461））–（（5120-4392）+（10240-10144））。耶！成功了。使用了一点点索引存储。我不确定这是什么，因为json文本消息的最大值是955字节，我们允许8000字节的行存储。我怀疑这是必要的，因为文本数据是模式的一部分，行外存储仍然可以用于大于8000字节的超大文本。 由于行内存储，我们还在表模式中看到了一些额外的内容。现在在模式定义中有两个额外的列用于行内存储和对象存储。

现在的问题是，插入新行时，行内行为是否仍然存在？让我们再插入1000000行试试。

耶！jsonMessage列永远在第行中。让我们看看一个全新的表是否可以用于行内存储，而不必从行外迁移到行内：

好的。行内存储适用于在文本列上使用"行内"设置创建的表。

默认情况下，您也可以使用alter database命令的inrow\U lob\U length参数强制行内存储。

很好。现在，大数据分析方法，在创建表时，您甚至不需要使用"in row（8000）"东西，除非您需要8000以外的东西。

数据压缩

关于LOB数据和压缩，首先要知道的是，无论您如何努力，行外LOB数据都不会被压缩。只有在设置inrow\u LOB\u length数据库选项时，淘客推广怎么做，行内LOB数据才会被压缩。这完全是无证的。您可能认为您正在压缩文本数据，但除非数据库设置中包含此特定选项，否则您不会这样做。所以让我们压缩行中的LOB数据，看看它是否比未压缩的好。在我看来，我们已经从798MB的行内压缩，下降到487MB的行内压缩。尺寸减少了39%。不错。