SQL Server 2016 上的巨大堆表和表壓縮

我的數據庫很大，最近我注意到幾個月前添加的一個新表是罪魁禍首。

這是表格腳本。

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Entry_tracker](
   [S.Number] [int] IDENTITY(1,1) NOT NULL,
   [EntryId] [varchar](50) NOT NULL,
   [EventNumber] [varchar](18) NOT NULL,
   [Data] [varbinary](max) NOT NULL,
   [TrackDateTime] [datetime] NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

ALTER TABLE [dbo].[Entry_tracker] ADD  CONSTRAINT [DF_Entry_tracker_TrackDateTime]  DEFAULT (getdate()) FOR [TrackDateTime]
GO

我收集了這張表的資訊，得知這張表大約有1600萬行，表大小為1.4TB。

不過，我認為桌子的大小對於沒有人來說是巨大的。的記錄。

應用程序不查詢此表。它只是儲存來自另一個表的相同條目的不同版本。

我檢查了碎片資訊，它顯示平均碎片為 0，平均使用空間為 93%。

由於我使用的是 SQL Server 2016，雖然我可以使用表壓縮，因此嘗試sp_estimate_data_compression_savings估計可能節省的空間。然而，結果顯示沒有節省。

size_with_current_compression_setting(KB)等於size_with_requested_compression_setting(KB)

誰能指導我找出這張桌子的問題？

這非常重要，因為這會佔用大量磁碟空間。

感謝你的幫助。

我仍然認為桌子的大小對於沒有人來說是巨大的。的記錄。

為什麼？是什麼讓你這麼說？

它的作用是儲存來自另一個表的相同條目的不同版本。

所以它包含版本，可能大或小，特別是考慮到：

[Data] [varbinary](max) NOT NULL,

你有沒有檢查過datalength()這些行，看看你那裡的用餐空間是否有一些大的行？

在我看來，根據數據，賦予函式的大小似乎是合理的。版本控制很少很小，除非它只是更改了字節，並且您使用各種算法來了解哪些字節，如何以及它是否建構了先前更改的版本。

引用自：https://dba.stackexchange.com/questions/240590