如何微調一個有問題的巨大堆表？
問題：
在一個非常重要的生產數據庫（MS SQL Server 2016 SP1 標準版）上，一個巨大的表導致了一個嚴重的性能問題。
關於有問題的表的事實：
- 沒有索引的堆表。
- 450 GB 大小。
- 超過 1.9 億條記錄。
- 每次執行簡單的 SELECT 查詢時，物理 I/O 活動超過 900 MB/s。如果查詢包含 WHERE 子句，則最糟糕。
- 對該表執行的查詢會導致應用程序 UI 出現 4-5 分鐘的延遲。
應用程序/系統製造商建議的解決方案：
- 將堆表轉換為聚集索引表。
針對建議解決方案的建議性能調整步驟：
截斷數據庫表（與客戶同意刪除超過 1 年的記錄）。
- 不要刪除記錄。將過去 1 年創建的記錄複製到臨時表。截斷原始表，然後將您從臨時表複製的記錄插入到清空的原始表中。
對 db 表進行碎片整理。
將 db 表從堆遷移到聚集表。
創建聚集索引。
創建維護作業並安排它定期重建聚集索引。
我對社區的問題：
您將如何提高這樣一個有問題的表的性能？您會在建議的性能調整步驟中添加或刪除什麼？
非常感謝，並提前非常感謝。
從這裡開始編輯：
好的，我不想一一回复所有評論。所以我正在編輯問題並添加更多資訊。
第一：我不是專業的 DBA。我會說一個高級初學者。這就是為什麼我在這裡盡可能多地向社區學習。
第二：我們兩週前剛得到這個客戶，我自己還沒有完全訪問環境。這個關於問題的資訊（事實），關於表的資訊直接來自客戶的系統管理員。
第三：因此，我不知道為什麼表在第一手是堆，沒有索引，他們讓它在沒有任何分區的情況下增長這麼多等等。
第四：建議的解決方案和建議的步驟不是我自己的，而是直接來自整個系統的製造商（這是一個眾所周知的統一通信系統，製造商是這方面最好的製造商。我想你們都知道哪一個）。
5th：我希望下周可以完全進入環境，在此之前，我只想分享我手頭的東西，並在陷入困境之前盡可能多地獲得意見/建議。
6th：因為不幸的是，我將把這個爛攤子從這裡拿走，並努力讓它變得更好、更順暢。
感謝所有已經抽出時間並回答的人。我已經有了一些了解。一旦我手頭有更多資訊，我肯定會分享更多資訊。
基於這些事實，190M 行，450GB，未索引的堆，長時間執行的查詢，您應該創建一個聚集列儲存索引並以壓縮列格式儲存數據。
但是，這可能不是最佳解決方案，因為您仍然有一個沒有鍵和索引的表，這很奇怪。
我對你的“建議的……步驟”有點困惑。
有些是一樣的（從堆遷移到聚集表與創建聚集索引是一樣的）。
目前尚不清楚您是否將它們作為彼此的讚美或替代品。
無論如何，您基本上有兩種選擇：
ALTER TABLE ... REBUILD擺脫所有空白空間，這可能是您的問題的原因。即，將其保留為堆。- 通過創建聚集索引將表轉換為聚集表。
我們大多數人都喜歡在我們的表上使用聚集索引，除非您有充分的理由不這樣做。即，我們不能說什麼最適合您。你的表是堆是有原因的嗎？如果是這樣，原因是什麼？與您發現的缺點相比，它有多強？等等。
至於聚集索引的碎片整理：不確定這對您是否有益。許多 DBA 進行碎片整理“只是因為”。如果您可以指出進行碎片整理的優勢（更少的“在磁碟上跳轉”和可能更高的頁面填充度），那麼一定要這樣做。