降低填充因子會導致更多的頁面拆分嗎？
我們一直有一個表上的頁面拆分問題，這是一個特別令人討厭的問題 - 它是數據庫中活動的審計日誌，並且已經增長超過 1TB。主要索引在記錄類型上，它是
NVARCHAR(100)- 因為當有 5 種記錄類型時您需要它 - 它比 aTINYINT和記錄 id 更有意義 - 它是 aNVARCHAR(200)而不是記錄的整數鍵。它們還涵蓋索引，鍵、舊值、新值等 - 非常廣泛。
這是一個舊系統，不幸的是，這種審計的程式碼無處不在，而不是集中在一個過程中。它無法更改，我們將經歷漫長的微服務重寫的痛苦過程。
因此，我將其中兩個索引的填充因子從 100% 降低到了 85%。
頁面拆分變得更糟。我會說大約 3 倍的頁面拆分。
這是一個普遍的結果嗎？大多數建議說要降低填充因子以提高頁面拆分性能。我可以理解為什麼它會這樣做，因為鍵中數據的寬度。
建議是進一步降低填充因子，還是恢復原狀？
假設您在 100% 的填充因子重建/重組與 85% 的填充因子重建/重組之後立即測量頁面拆分率，那麼更改填充因子確實不可能導致更多的頁面拆分。找到明確說明這一點的權威參考資料即使不是不可能，也很困難，但任何關於該主題的準確討論都隱含地說明了這一點。如果您的系統上的頁面拆分增加，這僅僅是由於對已添加或修改的數據進行了所需的索引。
重要的是要注意（因為您沒有提到它）您將需要重建或重新組織聚集索引，以便填充因子實際執行任何操作。填充因子僅在創建、重建或重組索引時使用——它不影響將多少數據放入新頁面。
正如大衛布朗在他的回答中指出的那樣，如果您的頁面已經分裂了很多，那麼已經有很多頁面中有大量可用空間。頁面拆分後，將有兩個頁面大約 50% 已滿。當您使用填充因子進行重組/重建時，所有頁面最終都已滿 85%，因此您實際上可能已經減少了頁面中的平均可用空間量。
請參閱為索引指定填充因子，Kendra Little 有一篇很好的文章，我也會在關於填充因子的5 件事中推薦關於此主題的文章。
另外，我可能會補充說，如果頁面拆分並沒有真正引起問題（使用者痛苦等），那麼它可能不值得“修復”。當您處理第三方應用程序或無法維護的事物時，通常值得考慮忽略一些低效操作的選項，除非它們確實導致了問題。