2016-09-01 25 views
0

我有一個表[ExampleSource]其中,SQL Server Management Studio中顯示以下存儲統計數據:爲什麼複製表的大小比原來小得多?

  • 指數空間:58 MB
  • 行數:28269319
  • 數據空間:4,567 MB

我使用以下命令複製表格,目的是基準各種索引配置:

SELECT * 
INTO [ExampleSource_Test] 
FROM [ExampleSource] 

查詢完成後,我發現一些令人驚訝的事情。在新的測試表中的數據的大小是顯着較小:

  • 指數空間:0.016 MB
  • 行數:28269319
  • 數據空間:2,820 MB

新表有相同的數據,只是沒有索引/主鍵。我添加了一個主鍵(與原件)到新的測試表,結果如下:

  • 指數空間:22.227 MB
  • 行數:28269319
  • 數據空間:2,820 MB

毫不奇怪,添加密鑰並不會增加數據空間。

下面是表的結構是否有幫助:

CREATE TABLE [dbo].[ExampleSource] 
(
    [C1] [bigint] NOT NULL, 
    [C2] [nvarchar](9) NOT NULL, 
    [C3] [nvarchar](5) NOT NULL, 
    [C4] [int] NOT NULL, 
    [C5] [nvarchar](1) NOT NULL, 
    [C6] [int] NOT NULL, 
    [C7] [bit] NOT NULL, 
    [C8] [date] NULL, 
    [C9] [decimal](29, 9) NULL, 
    [C10] [nvarchar](max) NULL, 
    [C11] [nvarchar](1) NULL, 
    [C12] [decimal](29, 9) NULL, 
    [C13] [nvarchar](3) NULL, 

    CONSTRAINT [PK_ExampleSource] 
     PRIMARY KEY CLUSTERED ([C2] ASC, [C3] ASC, [C4] ASC, [C5] ASC, [C6] ASC, [C1] DESC) 
     WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, 
      IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, 
      ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] 

原始表是多行插入一段時間的結果 - 在時間一般幾千元。沒有更新或刪除。我想知道對於原始表格(對於索引和數據)來說這個激烈的空間差異是什麼?我猜測SQL Server在一次全部複製時正在進行大量的數據優化/重組,但我正在尋找一個很好的解釋,爲什麼在原始表中可能會浪費太多空間。爲了防止這種膨脹,我可以/應該偶爾在桌面上運行一些維護嗎?

+0

注意:'nvarchar(1)'沒用 - 用'nchar(1)'代替。由於您只能存儲最多1個字符,因此使其成爲可變長度列只會增加每行2個字節的開銷(如果您改用'nchar(1)',則不會產生這種情況)。 'nvarchar(3)' –

+0

marc_s也一樣,我看到你關於nvarchar(1)的觀點。不過,從存儲角度看,同樣的邏輯也適用於nvarchar(3)。如果我有可變長度的項目,我不想使用nchar。修剪白色空間令人討厭。 – c31983

+0

同意 - 但如果您存儲的字符串是90%+總是隻有1或3個字符,這是值得的。 –

回答

0

一個可能的原因是原始表有一個或多個可變長度的列被丟棄。在這種情況下,儘量使用DBCC CLEANTABLE

第二個可能的原因是碎片化,嘗試通過查詢一下:

select a.index_id, name, avg_fragmentation_in_percent 
    from sys.dm_db_index_physical_stats (DB_ID(N'YourDatabase'), OBJECT_ID(N'ExampleSource'), NULL, NULL, NULL) a 
    join sys.indexes AS b ON a.object_id = b.object_id AND a.index_id = b.index_id 

如果因爲某些指標碎片,重新整理:

ALTER INDEX Index_name on Table_Name REORGANIZE WITH (LOB_COMPACTION=ON) 

如果這並沒有多大幫助,嘗試使用「ALTER INDEX REBUILD」(並刪除並重新創建索引作爲最後的選擇)。

+0

表結構自最初創建以來一直未更改。我很想嘗試DBCC CLEANTALBE,但是在你的答案中鏈接的文章表明它不應該作爲例行維護任務來執行。 – c31983

+0

也許索引不完整(我只是編輯了答案)。這個(很少)甚至可以添加新行。 – OlegAxenow

+0

在我看了編輯問題中的聚集索引之後,我認爲這個問題很可能是由於插入過程中的分割頁面造成的。 – OlegAxenow

相關問題