sql server压缩

The concept of data compression is not a new on for SQL Server Database Administrators , as it is was introduced the first time in SQL Server 2008. In that SQL Server version, you were able to configure the compression at the row and page levels on the table, index, indexed view or the partition. The row and page level compression is not the best choice in all cases, as it does not work well on the Binary Large Objects (BLOB) datatypes, such as the videos, images and text documents.

对于SQL Server数据库管理员来说，数据压缩的概念并不是一个新概念，因为它是SQL Server 2008中首次引入的。在该SQL Server版本中，您可以在行和页级别上配置压缩。表，索引，索引视图或分区。 在所有情况下，行和页面级压缩都不是最佳选择，因为它不适用于二进制大对象（BLOB）数据类型，例如视频，图像和文本文档。

SQL Server 2016 version keeps with the tradition of surprising us with the new features, enhancements and built-in functions. Starting from SQL Server 2016, an evolution occurred on the data compression technique that were used in the previous versions, by introducing two new built-in functions for compressing and decompressing data, which also available in all SQL Server 2016 editions, opposite to the page and row level compression that is available only in the Enterprise edition.

SQL Server 2016版本通过新功能，增强功能和内置功能保持了令我们惊讶的传统。 从SQL Server 2016开始，通过引入两个新的内置函数来压缩和解压缩数据，该版本在以前版本中使用的数据压缩技术发生了发展，该功能在所有SQL Server 2016版本中也都提供，与该页面相对行级压缩，仅在企业版中可用。

The Compress and Decompress functions use the Standard GZIP compression algorithm to compress the data itself. In this way, you can easily decompress the data that is compressed at the application side in your SQL Server instance or decompress the data that is compressed at the SQL Server side in your application, as both are using the same standard algorithm.

压缩和解压缩功能使用标准GZIP压缩算法来压缩数据本身。 这样，您可以轻松地解压缩SQL Server实例中在应用程序端压缩的数据，或解压缩应用程序中在SQL Server端压缩的数据，因为两者都使用相同的标准算法。

The basic syntax for the COMPRESS built-in function is:

COMPRESS内置函数的基本语法为：

COMPRESS (Expression)

压缩（表达）

Where the Expressions can be any value with nvarchar(n), nvarchar(max), varchar(n), varchar(max), varbinary(n), varbinary(max), char(n), nchar(n), or binary(n) data types. The result of the Compression function is a byte array of varbinary(max) data type representing the compressed content of the input value using the GZIP compression algorithm.

其中表达式可以是具有nvarchar（n），nvarchar（max），varchar（n），varchar（max），varbinary（n），varbinary（max），char（n），nchar（n）或二进制的任何值（n）数据类型。 压缩函数的结果是一个varbinary（max）数据类型的字节数组，代表使用GZIP压缩算法的输入值的压缩内容。

Also, the basic syntax for the DECOMPRESS built-in function is:

另外，DECOMPRESS内置函数的基本语法为：

DECOMPRESS (Expression)

DECOMPRESS（表达）

Where the Expressions can be any value with varbinary(n), varbinary(max), or binary(n) data types. Decompress function returns a value with varbinary(max) data type, representing the decompressed value of the binary input argument using the GZIP algorithm. You should explicitly cast the Decompress function result to the required data type in order get a readable result.

表达式可以是具有varbinary（n），varbinary（max）或binary（n）数据类型的任何值。 解压缩函数返回数据类型为varbinary（max）的值，该值表示使用GZIP算法的二进制输入参数的解压缩值。 您应该将Decompress函数结果显式转换为所需的数据类型，以便获得可读的结果。

You may ask yourself, where we can use these new built-in functions. You can benefit from the COMPRESS and DECOMPRESS functions in compressing big text columns, such as VARCHAR(MAX) or NVARCHAR(MAX) in addition to the large binary data, since the old compression technology at the page and row levels don’t work well with such data types. If you have an already compressed binary data such as jpeg and pdf, you will spend more CPU cycles without taking benefits from a good compression ratio. Moreover, you have the choice to compress it at SQL or the application side and decompress it at the second side, using the same GZIP compressing algorithm.

您可能会问自己，我们在哪里可以使用这些新的内置函数。 除了压缩大型二进制数据外，您还可以受益于COMPRESS和DECOMPRESS函数来压缩大型文本列，例如VARCHAR（MAX）或NVARCHAR（MAX），因为在页面和行级别的旧压缩技术不能很好地工作具有此类数据类型。 如果您已经压缩了jpeg和pdf等二进制数据，则将花费更多的CPU周期，而不会从良好的压缩率中受益。 此外，您可以选择使用相同的GZIP压缩算法在SQL或应用程序端进行压缩，然后在第二端进行解压缩。

工作的例子 (Worked example)

Let us start our practical demo that describes how we can use these two new built-in functions and the performance gain from using it. No special preparation is required to use the COMPRESS and DECOMPRESS functions, just the SQL Server instance that you use should be SQL Server 2016 version.

让我们开始一个实际的演示，该演示描述了如何使用这两个新的内置函数以及使用它们带来的性能提升。 使用COMPRESS和DECOMPRESS函数不需要任何特殊准备，只是您使用SQL Server实例应该是SQL Server 2016版本。

If you try to run the below simple T-SQL statement that compresses the provided text using SQL Server 2014 version instance:

如果您尝试运行以下简单的T-SQL语句，该语句使用SQL Server 2014版本实例压缩提供的文本：

 SELECT COMPRESS ('WELCOME FROM THE SQLSHACK COMMUNITY') AS Compressed_Value 

The query will fail, showing that the COMPRESS function is not a built-in function in this SQL Server version, which is prior to SQL Server 2016:

查询将失败，表明COMPRESS函数不是此SQL Server版本（SQL Server 2016之前的版本）中的内置函数：

Trying the same T-SQL statement in SQL Server 2016 version, which only passes a text value to the COMPRESS function:

在SQL Server 2016版本中尝试相同的T-SQL语句，该语句仅将文本值传递给COMPRESS函数：

 SELECT COMPRESS ('WELCOME FROM THE SQLSHACK COMMUNITY') AS Compressed_Value 

A byte array of VARBINARY(MAX) data type is returned from the previous query, showing a compressed representation of the provided text:

上一个查询返回了VARBINARY（MAX）数据类型的字节数组，显示了所提供文本的压缩表示形式：

This is simply how the COMPRESS function works. If we take the byte array value generated from the COMPRESS function, and pass it to the DECOMPRESS function as follows:

这就是COMPRESS函数的工作原理。 如果我们采用从COMPRESS函数生成的字节数组值，然后将其传递给DECOMPRESS函数，如下所示：

 SELECT DECOMPRESS (0x1F8B08000000000004000B77F571F6F77555700BF2F75508F17055080EF409F67074F656000AFB86FA7986440200ADAE249523000000) AS Decompressed_Value 

Another binary array of VARBINARY(MAX) data type will be returned from the DECOMPRESS function, showing the decompressed value of the compressed text. However, this does not represent the text that we have provided to the COMPRESS function:

DECOMPRESS函数将返回另一个VARBINARY（MAX）数据类型的二进制数组，其中显示了压缩文本的解压缩值。 但是，这并不代表我们提供给COMPRESS函数的文本：

To get a readable text representing the original value provided to the COMPRESS function, we need to explicitly cast the DECOMPRESS function result to a string data type as below:

为了获得表示提供给COMPRESS函数的原始值的可读文本，我们需要将DECOMPRESS函数的结果显式转换为字符串数据类型，如下所示：

 SELECT CAST(DECOMPRESS (0x1F8B08000000000004000B77F571F6F77555700BF2F75508F17055080EF409F67074F656000AFB86FA7986440200ADAE249523000000) AS VARCHAR(MAX)) AS Decompressed_Value 

Now we get the original text successfully, after casting the DECOMPRESS function result to VARCHAR(MAX) data type as follows:

在将DECOMPRESS函数结果转换为VARCHAR（MAX）数据类型之后，现在我们成功获取了原始文本，如下所示：

The string to be compressed can be also passed to the COMPRESS function as a parameter, and the result of the COMPRESS function can be passed too to the DECOMPRESS function as below:

也可以将要压缩的字符串作为参数传递给COMPRESS函数，并且COMPRESS函数的结果也可以传递给DECOMPRESS函数，如下所示：

 DECLARE @NormalString VARCHAR(MAX) = 'WELCOME FROM THE SQLSHACK COMMUNITY'SELECT @NormalString As StringtoBeCompressed,COMPRESS(@NormalString) AS AfterCompression , DECOMPRESS(COMPRESS(@NormalString)) AfterDecompression,CAST(DECOMPRESS(COMPRESS(@NormalString)) AS VARCHAR(MAX)) AS  AfterCastingDecompression 

The result of the previous query shows the original string to be compressed, the COMPRESS function result, the DECOMPRESS function result and the casted result of the DECOMPRESS function that represents the original text too:

上一个查询的结果显示了要压缩的原始字符串，COMPRESS函数结果，DECOMPRESS函数结果以及也代表原始文本的DECOMPRESS函数的强制转换结果：

Suppose that we need to compress the below two strings, that have the same value but different data types using the COMPRESS function:

假设我们需要使用COMPRESS函数压缩以下两个字符串，这些字符串具有相同的值但数据类型不同：

 DECLARE @NormalStringVarchar VARCHAR(MAX) = 'WELCOME FROM THE SQLSHACK COMMUNITY'DECLARE @NormalStringNVarchar NVARCHAR(MAX) = 'WELCOME FROM THE SQLSHACK COMMUNITY'SELECT COMPRESS(@NormalStringVarchar) AS AfterCompressionVarchar ,COMPRESS(@NormalStringNVarchar) AS AfterCompressionNVarchar 

The result will show us that, although these two strings have the same value, it will be compressed to different values, as they have different data types, one with VARCHAR data type and the second one with NVARCHAR data type, as follows:

结果将向我们显示，尽管这两个字符串具有相同的值，但是由于它们具有不同的数据类型，它们将被压缩为不同的值，一个具有VARCHAR数据类型，另一个具有NVARCHAR数据类型，如下所示：

The question now is, will the string length affect the compression effectiveness? To answer this question, let us take three strings with different lengths and compare the data length of the original string and the compression result as follows:

现在的问题是，字符串长度会影响压缩效果吗？ 为了回答这个问题，让我们采用三个不同长度的字符串，并比较原始字符串的数据长度和压缩结果，如下所示：

 DECLARE @NormalString1 VARCHAR(MAX) = 'WELCOME FROM THE SQLSHACK COMMUNITY'DECLARE @NormalString2 VARCHAR(MAX) = 'WELCOME FROM THE SQLSHACK COMMUNITY, WE ARE HAPPY THAT YOU VISITING US, READING AND ENJOYING THE SITE CONTENT'DECLARE @NormalString3 VARCHAR(MAX) = 'WELCOME FROM THE SQLSHACK COMMUNITY, WE ARE HAPPY THAT YOU VISITING US, READING AND ENJOYING THE SITE CONTENT, WHERE YOU CAN FIND ALL USEFUL SQL SERVER DEVELOPMENT AND ADMINISTRATION ARTICLES WRITTEN BY OUR PROFESSIONALS FROM ALL OVER THE WORLD ' SELECT DATALENGTH(@NormalString1) String1Length, DATALENGTH(COMPRESS(@NormalString1))   String1CompressedLength,       DATALENGTH(@NormalString2) String1Length, DATALENGTH(COMPRESS(@NormalString2))   String1CompressedLength,	   DATALENGTH(@NormalString3) String1Length, DATALENGTH(COMPRESS(@NormalString3))   String1CompressedLength 

The result will clearly show us that, as the length of the original string increases, the compression effectiveness increases. The compression is not useful in the case of the small string, where the length of the compressed string is larger than the original one. The compression effectiveness of the string with 109 length is 0.046, where we gain 0.28 when compressing a larger string with 245 length:

结果将清楚地表明，随着原始琴弦的长度增加，压缩效果也将增加。 在小字符串的情况下，压缩不起作用，因为小字符串的长度大于原始字符串的长度。 长度为109的字符串的压缩效率为0.046，当压缩长度为245的较大字符串时，压缩效率为0.28：

The data type of the string to be compressed affects also the compression effectiveness. Assume that we have the same previous large string to be compressed, but this time with XML type, taking into consideration that we should cast it to pass it to the COMPRESS function:

要压缩的字符串的数据类型也会影响压缩效率。 假设我们有相同的先前大字符串要压缩，但是这次是XML类型，考虑到我们应该将其转换为将其传递给COMPRESS函数：

 DECLARE @xml XML;SET @xml =  '
    
     WELCOME FROM THE SQLSHACK COMMUNITY, WE ARE HAPPY THAT YOU VISITING US, READING AND ENJOYING THE SITE CONTENT, WHERE YOU CAN FIND ALL USEFUL SQL SERVER DEVELOPMENT AND ADMINISTRATION ARTICLES WRITTEN BY OUR PROFESSIONALS FROM ALL OVER THE WORLD 
    ';SELECT datalength(@xml) AS StringLength,datalength(COMPRESS (cast (@xml as nvarchar(max)))) AS CompreesedStringLength 

The result will show that, with the XML data type, the compression is more efficient, as we gain with the same string about 0.5 compression effectiveness, compared to the previous result of 0.28 when having the VARCHAR data type:

结果将表明，使用XML数据类型时，压缩效率更高，因为在使用相同字符串的情况下，压缩效率约为0.5，而使用VARCHAR数据类型时，先前的结果为0.28：

Until this step, we are familiar with how we can use the COMPRESS and DECOMPRESS functions by providing it with the text to be compressed directly or as parameters. Suppose that we need to compress already existing data from one of our tables. Moreover, check if we will take benefits from compressing this data or not. We will start by creating the source table as follows:

在此步骤之前，我们已经熟悉如何通过向COMPRESS和DECOMPRESS函数提供直接压缩或作为参数压缩的文本来使用它们。 假设我们需要从一张表中压缩已经存在的数据。 此外，请检查我们是否将从压缩此数据中受益。 我们将从创建源表开始，如下所示：

 USE SQLShackDemo GOCREATE TABLE Products_Normal( ProdID int PRIMARY KEY,  ProdName nvarchar(50),  ProdDescription nvarchar(MAX) ) GO) 

Then, filling it with 1,000 records of test data using the test data generation tool:

然后，使用测试数据生成工具将其填充1000条测试数据记录：

The source table is ready now. We will create a new table with the same data as the Product_Normal table, except for the ProdDescription column that will be compressed in that table easily using the COMPRESS function:

源表现在准备就绪。 我们将创建一个具有与Product_Normal表相同的数据的新表，除了ProdDescription列将使用COMPRESS函数轻松在该表中进行压缩：

 SELECT [ProdID]      ,[ProdName]      ,COMPRESS([ProdDescription]) AS ProdDescriptionINTO [Products_Compressed]FROM [Products_Normal]GO 

Finally, we will create a new table that contains the same data as the Product_Compressed table except for the ProdDescription column that will be decompressed in that table using the DECOMPRESS function:

最后，我们将创建一个新表，该表包含与Product_Compressed表相同的数据，除了ProdDescription列将使用DECOMPRESS函数在该表中解压缩：

 SELECT [ProdID]      ,[ProdName]      ,DECOMPRESS([ProdDescription])  AS ProdDescriptionINTO [Products_DECompressed]FROM [Products_Compressed]GO 

For now, we have three tables; the Product_Normal table that contains the original data with no changes, the Product_Compressed table that contains the compressed values of the ProdDescription column, and the Product_DECompressed table that contains the decompressed values of the ProdDescription column. Let us query the ProdDescription column values from the three tables by joining the three tables together depending on the ProdID values:

现在，我们有三个表。 Product_Normal表包含原始数据，且没有更改； Product_Compressed表包含ProdDescription列的压缩值； Product_DECompressed表包含ProdDescription列的解压缩值。 让我们通过根据ProdID值将三个表连接在一起来查询三个表中的ProdDescription列值：

 SELECT TOP 5 N.ProdDescription, COM.ProdDescription, DECOM.ProdDescription  FROM [Products_Normal] NJOIN [Products_Compressed] COMON N.ProdID = COM.ProdIDJOIN [Products_DECompressed] DECOMON DECOM.ProdID = COM.ProdID 

You can see from the result the original values, the compressed values and the decompressed values of the ProdDescription column:

您可以从结果中看到ProdDescription列的原始值，压缩值和解压缩值：

Again, the decompressed values of the ProdDescription column from the DECOMPRESS function do not match the actual string values. So that, we need to cast the decompressed values using the correct data type as follows:

同样，来自DECOMPRESS函数的ProdDescription列的解压缩值与实际的字符串值不匹配。 因此，我们需要使用正确的数据类型来转换解压缩的值，如下所示：

 SELECT TOP 5 N.ProdDescription, COM.ProdDescription, DECOM.ProdDescription ,  CAST(DECOM.ProdDescription AS VARCHAR(MAX)) AS Decompressed_DataFROM [Products_Normal] NJOIN [Products_Compressed] COMON N.ProdID = COM.ProdIDJOIN [Products_DECompressed] DECOMON DECOM.ProdID = COM.ProdID 

However, the decompressed value still does not match the original string value. As we mentioned previously, we should cast the DECOMPRESS result using the correct data type, which is the data type of the original string that is NVARCHAR in our case, not VARCHAR as in the previous query:

但是，解压缩后的值仍与原始字符串值不匹配。 如前所述，我们应该使用正确的数据类型转换DECOMPRESS结果，该数据类型是原始字符串的数据类型，在本例中为NVARCHAR，而不是前一个查询中的VARCHAR：

Casting the decompressed result using the correct data type:

使用正确的数据类型转换解压缩的结果：

 SELECT TOP 5 N.ProdDescription, COM.ProdDescription, DECOM.ProdDescription ,  CAST(DECOM.ProdDescription AS NVARCHAR(MAX)) AS Decompressed_DataFROM [Products_Normal] NJOIN [Products_Compressed] COMON N.ProdID = COM.ProdIDJOIN [Products_DECompressed] DECOMON DECOM.ProdID = COM.ProdID 

We will get the desired output now. The same result as the original string:

我们现在将获得所需的输出。 结果与原始字符串相同：

For now, we understand how to use the COMPRESS and DECOMPRESS functions to deal with the existing data.

现在，我们了解了如何使用COMPRESS和DECOMPRESS函数处理现有数据。

展示价值 (Demonstrating the value)

OK. What may encourage us to use it is the benefits that we will take from using it. Let us compare the space consumed by storing the original data and the compressed data using the SP_Spaceused system object:

好。 鼓励我们使用它的是使用它所带来的好处。 让我们比较使用SP_Spaceused系统对象存储原始数据和压缩数据所消耗的空间：

 SP_Spaceused 'Products_Normal'GOSP_Spaceused 'Products_Compressed'GO 

It is clear from the result that storing the same 1,000 records, as compressed values will save 320 KB in our case, which is about 56% of the total space. You can imagine the space that you will save by compressing large tables:

从结果可以明显看出，存储相同的1000条记录，因为在我们的案例中，压缩值将节省320 KB，约占总空间的56％。 您可以想象压缩大型表将节省的空间：

Not yet convinced? Let us compare internally the number of pages that will be consumed by storing the original data and the compressed data:

还没说服？ 让我们在内部比较通过存储原始数据和压缩数据将消耗的页面数：

 SELECT  OBJECT_NAME(IDX.object_id) [TableName], ptx.rows   [RowNum], SUM(ptxS.used_page_count) [PageCount]FROM sys.indexes  IDXINNER JOIN sys.partitions ptxON ptx.object_id = IDX.object_idAND ptx.index_id = IDX.index_idINNER JOIN sys.dm_db_partition_stats  ptxSON ptxS.partition_id = ptx.partition_idWHERE IDX.object_id IN (OBJECT_ID('Products_Normal'), OBJECT_ID('Products_Compressed'))GROUP BY IDX.object_id, ptx.rows 

Again, compressing the data using the COMPRESS function saved about 42 pages, which is 56% of the total number of pages required to store the data:

同样，使用COMPRESS函数压缩数据可以节省大约42页，这是存储数据所需的总页数的56％：

What about the performance gain that we may take from using the compressed data?

使用压缩数据可能带来的性能提升如何？

Let us compare between reading from the original table and the compressed table by enabling the TIME and IO statistics, in addition to enabling the actual execution plan, using the below script:

除了启用实际的执行计划之外，我们还使用以下脚本通过启用TIME和IO统计信息来比较从原始表和压缩表读取数据：

 SET STATISTICS TIME ONSET STATISTICS IO ON SELECT TOP 100 * FROM Products_Normal WHERE ProdID >554GOSELECT TOP 100 * FROM Products_Compressed WHERE ProdID >554 SET STATISTICS TIME OFFSET STATISTICS IO OFF 

Wow! The time required to retrieve the data from the compressed table is about 32% of the time required to retrieve the data from the original table:

哇！ 从压缩表中检索数据所需的时间约为从原始表中检索数据所需的时间的32％：

The IO statistics show us that the logical reads required to read the data from the compressed table is about 0.3 of the logical reads required to read from the original table:

IO统计数据表明，从压缩表读取数据所需的逻辑读取大约是从原始表读取逻辑读取的0.3：

You can derive from the execution plans below that the weight of reading the compressed data is 38%, although it performed a table scan, compared to reading from the original table that consumes 62% of the overall load:

从下面的执行计划中可以得出，尽管压缩表执行了表扫描，但是读取压缩数据的权重为38％，而从原始表中读取则占了总负载的62％：

Reading the compressed data and displaying it for the end users has no practical purposes, as this binary data is unintelligible for them. However, we can save the compressed data for the application that will read it, decompress it and display the result for the end users.

读取压缩数据并将其显示给最终用户没有实际目的，因为此二进制数据对他们来说是难以理解的。 但是，我们可以为将要读取，解压缩并为最终用户显示结果的应用程序保存压缩数据。

In addition, you can save it as compressed data in your table and decompress it in the fly before displaying it to the end users. However, nothing cheap anymore. If we compare between reading the original data and reading the casted decompress data, which will return the same result:

另外，您可以将其另存为表中的压缩数据，并在将其显示给最终用户之前即时对其进行解压缩。 但是，再也没有便宜了。 如果我们在读取原始数据和读取强制转换的解压缩数据之间进行比较，这将返回相同的结果：

 SET STATISTICS TIME ONSET STATISTICS IO ON SELECT TOP 100 ProdDescription FROM Products_Normal WHERE ProdDescription  like '%AMM%'GOSELECT TOP 100 CAST (decompress(ProdDescription) AS NVARCHAR(MAX)) FROM Products_Compressed WHERE CAST (ProdDescription AS NVARCHAR(MAX))  like '%AMM%' SET STATISTICS TIME OFFSET STATISTICS IO OFF 

You will see that, reading the casted decompressed data will take about 3 times, the time required to retrieve the same data from the original table, with extra CPU time cycles required to read that data:

您将看到，读取转换的解压缩数据将花费大约3倍的时间，这是从原始表中检索相同数据所需的时间，而读取该数据则需要额外的CPU时间周期：

Although the logical reads required to retrieve the casted decompressed data is about 67% the logical reads required to read the original data, reading the casted decompressed data required 49 read-ahead reads which is not consumed while reading the original data. This means that there is an extra process of reading the data from the disk and placing it to the data cache:

尽管检索铸造的解压缩数据所需的逻辑读取约为读取原始数据所需的逻辑读取的67％，但读取铸造的解压缩数据需要49个预读，而读取原始数据时不会消耗这些读取。 这意味着有一个额外的过程来从磁盘读取数据并将其放置到数据缓存中：

结论： (Conclusion:)

SQL Server 2016 introduces two new built-in functions that ease and expand the SQL data compression world. The COMPRESS function that is used to compress the text data into a smaller binary data, and the DECOMPRESS function that works opposite to the COMPRESS function by decompressing the compressed binary data and return a meaningless binary data, that you should cast to correct data type to get the original text that is compressed.

SQL Server 2016引入了两个新的内置函数，这些函数简化和扩展了SQL数据压缩世界。 COMPRESS函数用于将文本数据压缩为较小的二进制数据，DECOMPRESS函数与COMPRESS函数相反，该函数通过解压缩压缩的二进制数据并返回无意义的二进制数据，应将其转换为正确的数据类型获取压缩的原始文本。

We saw clearly during the demo the different way of using these functions and the benefits from using it. We saw how the compressed data takes less space when keeping it in the tables compared to the original data, and that it requires less time to retrieve it from the table. We saw also the other side of the sword, while decompressing and casting the data before displaying it to the users will consume more time and space. You can benefit from these functions by saving the decompressed data on your table and decompress it at the application side to work on it. These new functions are available now, it is yours to start testing and checking if they will rescue you in one of your scenarios.

在演示过程中，我们清楚地看到了使用这些功能的不同方法以及使用它们的好处。 我们看到与原始数据相比，压缩后的数据在保留在表中时如何占用更少的空间，并且从表中检索数据所需的时间更少。 我们还看到了剑的另一面，在将数据解压缩并转换为数据显示给用户之前将花费更多的时间和空间。 通过将解压缩的数据保存在表上并在应用程序侧对其进行解压缩以进行处理，您可以从这些功能中受益。 这些新功能现已上市，您可以开始测试并检查它们是否可以在您的一种情况下解救您。

有用的链接： (Useful Links:)

翻译自:

sql server压缩