壓縮 NVARCHAR(MAX) 的替代方法？
我正在嘗試壓縮一些具有
NVARCHAR(MAX)欄位的表。不幸的是，row壓縮page並沒有預期的影響（20 GB 表僅節省了約 100/200 MB）。此外，我無法應用列儲存和列儲存歸檔壓縮，因為它們不支持NVARCHAR(MAX)欄位壓縮。誰能告訴我這裡是否有其他選擇？
我也猜想
row和page壓縮沒有效果，因為NVARCHAR(MAX)列的內容是唯一的。
頁壓縮和行壓縮都不壓縮 BLOB。
由於它們的大小，大值數據類型有時與特殊用途頁面上的普通行數據分開儲存。數據壓縮不適用於單獨儲存的數據。
如果要壓縮 BLOB，則需要將它們儲存為
VARBINARY(MAX)並應用您選擇的流壓縮算法。例如GZipStream. 有很多範例如何做到這一點，只需搜尋 GZipStream 和 SQLCLR。
（現在）可能有兩種方法可以完成自定義壓縮：
- 從 SQL Server 2016 開始，有COMPRESS和DECOMPRESS的內置函式。這些函式使用 GZip 算法。
- 使用 SQLCLR 實現您選擇的任何算法（正如@Remus 在他的回答中提到的那樣）。此選項在 SQL Server 2016 之前的版本中可用，一直到 SQL Server 2005。
GZip 是一個簡單的選擇，因為它在 .NET和受支持的 .NET Framework 庫中可用（程式碼可以在程序集中
SAFE）。或者，如果您想要 GZip 但不想處理編碼/部署它，您可以使用免費版本的SQL# SQLCLR 庫（我是該庫的作者）中提供的Util_GZip和Util_GUnzip函式。如果您決定使用 GZip，無論您自己編寫程式碼還是使用 SQL#，請注意 .NET 中用於執行 GZip 壓縮的算法在 Framework 4.5 版中有所更改（請參閱 MSDN 上的“備註”部分GZipStream 類的頁面）。這意味著：
- 如果您使用的是 SQL Server 2005、2008 或 2008 R2——都連結到處理 Framework 2.0、3.0 和 3.5 版本的 CLR v 2.0——那麼在 Framework 4.5 版本中所做的更改沒有效果，不幸的是你被困在了.NET 的原始、糟糕的算法。
- 如果您使用的是 SQL Server 2012 或更新版本（截至 2014 年和 2016 年）——所有這些都連結到處理 Framework 版本 4.0、4.5.x、4.6 的 CLR v 4.0——那麼您可以使用更新、更好的算法。唯一的要求是您已將執行 SQL Server 的伺服器上的 .NET Framework 更新為 4.5 或更高版本。但是，您不必使用 GZip，並且可以自由地實現任何類似的算法。
**請注意：**上面提到的所有方法都更像是“解決方法”，而不是實際的替代品，即使它們在技術上是“壓縮 NVARCHAR(MAX)”數據的替代方法。不同之處在於，使用 SQL Server 提供的內置數據壓縮 -
row並且page- 壓縮是在幕後處理的，並且數據仍然可用、可讀和可索引。但是將任何數據壓縮成一個VARBINARY意味著您節省了空間，但放棄了一些功能。的確，一個 20k 的字元串無論如何都不能索引，但它仍然可以用於WHERE子句，或任何字元串函式。為了使用自定義壓縮值執行任何操作，您需要動態解壓縮它。壓縮二進製文件（PDF、JPEG 等）時，這不是問題，但這個問題是特定於NVARCHAR數據的。