提高事實表的性能

我有一個事實表 CardTransactionFact

表結構

TABLE [dbo].[CardTransactionFact]
   [CardTransactionID] [int] IDENTITY(1,1) NOT NULL,
   [TransactionTerminalID] [int] NOT NULL,
   [SourceAccountTypeID] [int] NULL,
   [DestinationAccountTypeID] [int] NULL,
   [RimNo] [varchar](15) NULL,
   [CaptureCodeID] [int] NOT NULL,
   [RoutingCodeID] [int] NOT NULL,
   [ProcessingCodeID] [int] NOT NULL,
   [ActionCodeID] [int] NOT NULL,
   [NetworkCodeID] [int] NOT NULL,
   [ProductCodeID] [int] NOT NULL,
   [AcquiringCountryCodeID] [int] NOT NULL,
   [IssuingCountryCodeID] [int] NOT NULL,
   [TransactionCurrencyCodeID] [int] NOT NULL,
   [AmountBD] [decimal](18, 3) NOT NULL,
   [LocalCurrencyCodeID] [int] NOT NULL,
   [CardIssuerBank] [int] NOT NULL,
   [CardTypeID] [int] NOT NULL,
   [SuspectTransactionFlag] [char](1) NOT NULL,
   [ReversalTransactionFlag] [char](1) NOT NULL,
   [LocalTransactionDateKey] [int] NOT NULL,
   [LocalTransactionHourKey] [int] NOT NULL,
   [BBKRole] [char](1) NOT NULL,
   [AmountRangeKey] [int] NULL,
   [CustomerKey] [int] NULL

大小：11GB 行數：56,959,828

---

現在訪問這個表變得非常困難，一個簡單Select count(*) from CardTransactionFact的需要幾個小時才能執行。

表中的大多數列只是整數，這就是我沒有做任何索引的原因。

你認為我應該做些什麼來改進這個表，並提高查詢這個表的速度

1. 如果索引我應該索引哪些列以及為什麼
2. 對錶進行分區是個好主意嗎
3. 任何其他建議

這裡有很多問題，謝天謝地，有很多可以修復的。

問題：

• 你有一堆。很有可能這是非常分散的，並且頁面分佈在整個 82GB 數據文件中。有關檢查碎片的指導，請參閱sys.dm_db_index_physical_stats。
• 您只有 6GB 的記憶體，如果幸運的話，緩衝池可能有 4GB 可用。
• 從字裡行間看，您正在使用狗慢速 SATA 旋轉驅動器。
• 對錶的掃描將需要 11GB 的隨機 IO 跨越該狗慢速驅動器，並將緩衝池完全攪動 3 次。

修復：

• 在表上創建聚集索引。CardTransactionId 看起來是目前唯一明智的選擇。
• 你迫切需要記憶。對於 82GB 的數據倉庫來說，128GB 是合理的。
• 您的 IO 嚴重不足。SSD 將是最便宜、最快的解決方案。

11GB 不適合 6GB，真的就是這麼簡單。一個非常粗略的估計表明，該表將佔用約 150 萬個 8KB 頁面，假設 100 IOPS 從磁碟讀取大約需要 4 小時（假設最壞的情況，100% 隨機讀取，無預讀等）。

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