實施 ISCSI SAN 固態驅動器時對基於成本的優化器 (CBO) 有何影響
Microsoft Technet 文章建議創建輔助文件組作為預設文件組（請參閱下面的參考資料）。輔助文件組應該有許多文件，比如四個，每個文件都放在單獨的磁碟上。作為同事的附加經驗法則，文件數應等於 CPU 核心數。
我的理解是，這種設置非常適合機械旋轉磁碟驅動器，因為旋轉磁碟驅動器比固態驅動器慢得多，因此可以通過來自多個磁頭的流數據來提高性能。這種理解正確嗎？
如果是，那麼我的問題是基於成本的優化器是否考慮了較新的固態驅動器？當切換到新的固態驅動器時，旋轉硬碟驅動器的性能瓶頸似乎消失了。我們的 IT 運營團隊告訴我，雖然我目前被分配了一個虛擬驅動器，但數據實際上儲存在具有多個固態驅動器的 ISCSI SAN 上。
這個問題旨在嘗試回答這種規模的大型數據庫的最佳設置是什麼：
- 我應該有一個只有一個文件的預設輔助文件組嗎？
- 我應該有一個預設的輔助文件組，其中的文件數等於 CPU 上的核心數嗎？
- 使用固態驅動器時對數據庫表進行分區是否會提高性能？
我正在進行的目前項目需要一個規模為幾 TB 的可擴展數據庫，用於儲存大量日誌數據。一個一周的樣本大約有 1.5 億條記錄，我們需要儲存滾動 3 年的日誌。因此，我現在正在查看長時間執行的查詢以查找數據。我已將索引調整到幾乎所有工作都歸因於非聚集索引查找的程度；優化器不建議添加缺失的索引。
筆記
Microsoft SQL Server 上的許可目前按 CPU 核心。因此，在這個問題上投入更多核心是很敏感的，尤其是在這不會提高性能的情況下。
此外，我目前正在 SQL Server 2014 上進行開發，但將遷移到 SQL Server 2017 進行開發和生產。
更新 1
該項目將每晚載入日誌，我預計很少（可能沒有）更新或刪除，因為日誌根本不會改變 - 所以它們不會被重新載入。出於分析目的，將讀取其他所有內容。
系統表的 PRIMARY 文件組，其中 SECONDARY 預設文件組用於其他所有文件。此問題底部引用的連結解釋了這樣做的原因。
將為表分區創建單獨的文件組。數據庫中的其他表足夠小，它們將駐留在 SECONDARY 文件組中 - 我只對兩個表進行分區，其中一個超過 1 億條記錄（按 IDENTITY 行號分區），另一個將進入數十億條記錄（按時間劃分
$$ monthly $$). 我計劃在 3 年內按月分區。因此，將有 36 個分區。我將為每年創建文件組，然後將 12 個文件放入相應的年度文件組中。分區策略是為了減少讀取時間，因為為了分析目的會進行大量數據掃描。年度文件組策略嚴格來說是為了便於 DBA 維護，他們可以通過刪除單個文件組來刪除一年的數據。
參考：
基於成本的優化器（目前）不會根據您的硬體更改其估計的 IO 成本。
您說這個問題旨在回答哪種文件組和分區策略最適合您的環境。在那種情況下，誰在乎優化器做了什麼？問題是什麼在您的環境中執行良好，真正的答案是測試它。
根據經驗，添加文件組以提高維護或可管理性，並添加文件以提高性能。當然，並非所有工作負載或場景都會受益於額外的文件或文件組。舉幾個例子：
- 考慮一個具有許多 CPU 和一個使用者數據庫的數據文件的 Windows 伺服器。只有一個數據文件意味著我只有一個 LUN。可以創建需要比單個 LUN 提供的更多 I/O 的工作負載。如果工作負載受到 I/O 的限制，則可以通過向數據庫添加更多文件來提高性能，每個文件都位於自己的 LUN 上。您可以通過查看等待統計資訊來判斷您是否處於這種情況。
- 考慮一個具有許多 CPU 和一個使用者數據庫的數據文件的 Windows 伺服器。可能會創建一個工作負載，該工作負載會因只有一個文件而導致邏輯爭用而成為瓶頸。例如，更改數據的某些類型的查詢都需要一次修改同一個 PFS 頁面。如果工作負載因記憶體中的邏輯爭用而成為瓶頸，則可以通過添加更多文件來提高性能，即使這些文件與以前位於同一 LUN 上也是如此。擁有額外的文件意味著有更多的“活動”PFS 頁面可以減少爭用。有關更多詳細資訊，請參閱本文。
- 您可以將表或分區分配給特定的文件組。您不能對文件執行此操作。因此，如果您有想要清除的舊數據並且想要回收所有儲存，那麼文件組可能是您的一個不錯的選擇。將所有使用者數據放在輔助文件組中具有某些人發誓的一些維護好處。重要的一點是文件組應該被認為有助於管理而不是性能。