桌子大小重要嗎？
我有一個這樣的表（雖然有更多的列）：
CREATE TABLE [dbo].[MyTable]( [SnapKey] [int] NOT NULL, [SnapDt] [smalldatetime] NOT NULL, [Company] [varchar](4) NOT NULL, [ProfitCenter] [varchar](10) NOT NULL, [CostCenter] [varchar](10) NOT NULL, ) ON [MyPartition]([SnapKey]) CREATE CLUSTERED INDEX [IDX1] ON [dbo].[MyTable] ( [SnapKey] ASC )表在SnapKey上**分區。SnapKey 是 SnapDt 的日期部分，儲存為整數，例如 20160131 和 20160229。
每個分區僅包含 1 個 SnapKey。對於每個 SnapKey 分區，我有大約 500 萬行。目前我只在我的表中保留每個月的最後一天。
我總是使用 SnapKey 進行查詢。數據不會發生更新。對於每一天，數據都填充到表中，然後我們在該月執行一些報告。
問題：如果我每月保留 6 天的數據，而不是每月 1 天，我的查詢會執行得更慢嗎？
我找不到任何明確的答案，所以我試圖用數據填充表格，但我的儲存空間用完了，所以我決定問你，看看是否有任何理論上的解釋。
澄清
通過再儲存 5 天，我們將儲存 6 倍的數據（用於歷史報告）。我們將保留該月的最後 6 天，而不是僅保留最後一天。
我們的查詢不會改變，我們的報告仍然超過 1 天（一個 SnapKey）。
我們每個月有一個 SnapKey。現在我們有
20160131 20160229 20160330…等等。每個月末一個 SnapKey。
再過 5 天，SnapKey 將如下所示：
20160126, 20160127, 20160128, 20160129, 20160130, 20160131 20160224, 20160225, 20160226, 20160227, 20160228, 20160229 20160325, 20160326, 20160327, 20160328, 20160329, 20160330 ...and so on您會看到我們儲存了 6 倍以上的數據，但在我們的查詢中仍然只使用一個 SnapKey。這意味著我們始終擁有：
WHERE SnapKey = xxxxxxxx在我們所有的查詢中。
如果我每月將數據保留 6 天，而不是每月 1 天，我的查詢會執行得更慢嗎？
這取決於。
否- 如果您執行與以前完全相同的查詢（根本無法訪問新數據）。
SQL Server 的分區實現為每個分區創建一個單獨的行集，因此當您創建分區索引時，它會為每個分區創建一個*單獨的 b 樹結構**（請注意，分區堆也存在）。
因此，從現有分區的角度來看，簡單地添加更多分區並不會改變 - 索引完全相同。您的查詢僅訪問單個分區，因此沒有任何變化。
也許- 如果您在任何階段查詢新數據。將新數據帶入記憶體可能會替換原始查詢所需的數據，具體取決於您擁有的記憶體量。如果更改導致新的物理 I/O，您將看到對性能的影響，其嚴重程度取決於儲存子系統的能力。
從這些連結：
當聚集索引有多個分區時，每個分區都有一個 B 樹結構，其中包含該特定分區的數據。
當非聚集索引有多個分區時，每個分區都有一個 B 樹結構，其中包含該特定分區的索引行。
當一個堆有多個分區時，每個分區都有一個堆結構，其中包含該特定分區的數據。
您還可以通過查看系統目錄視圖（如sys.partitions ）自己探索這一點，其中顯示了包含特定分區行的結構的hobt_id （堆或 b-tree id）。