包含 40000 個產品的表上的碎片有多大可能會影響性能

所以數據庫管理不是我的強項，所以我有幾個問題。

這一切都與我正在查看的網站的性能有關，並且花費了相當多的時間進行研究/診斷。

• 有兩個站點，一個測試站點和一個實時站點。
• 我注意到與測試站點相比，實時站點上的頁面載入時間要長得多。
• 測試站點的規格非常低 - VPS 2 具有 14GB RAM 的虛擬處理器和 SQL + 網站在同一 VPS 上執行
• 現場網站的規格是 4 台專用伺服器，全部配備 8 個虛擬處理器和 16GB RAM
• 實時站點使用單獨的 SQL 專用伺服器，具有 16 個虛擬處理器和 112GB RAM
• 該網站在任何時候平均有 120 個並髮使用者，但可能會在 70 到 150 之間波動，當我們發送電子郵件活動時，它可以達到 400。當我們達到 400 時，您所期望的 cpu 可以達到 100%，具體取決於使用者的操作正在網站上進行，但它們與 RAM 的表現相當好。

我希望實時網站實際上比測試網站執行得更快，但事實並非如此。我查看了程式碼，但我堅信這是由於數據庫。直播網站備份時數據庫大小超過50GB，測試網站4GB。

兩個數據庫都非常分散，我想知道碎片對性能的影響有多大？

還有因為直播網站比測試網站大很多倍，那麼高碎片化對直播網站性能的影響會比測試網站大很多嗎？

這是 products 表中的索引之一的擷取。

因為我之前從未處理過這個關於重建/刷新索引的一些技巧。

我是否應該將網站置於維護模式，以便在重建/刷新索引時沒有人可以與表互動？

一個有 12 個索引和 40000 個產品的表需要多長時間？

謝謝

根據您提供的數據——

共有 67 頁。這麼小的表的索引碎片不會影響性能。我不會擔心您提到的表的索引碎片。

您應該更新表統計資訊，以便 sql server 可以生成更好的查詢計劃。

我會開始我的故障排除

• 執行sp_Blitz：整體執行狀況檢查

閱讀：不要再擔心 SQL Server 碎片了

指數在使用過程中（時間）必然會出現碎片化。重要的是它是否會影響性能。

通常我們不擔心 page_count < 500 的索引。（我們和我的團隊一樣）但是，對於特定的 page_count 沒有硬性規定。在我之前的商店中，我們在 Ola 腳本中將限制設置為 1000頁數。但是是的，索引的 page_count = 67，碎片總是在較高的一側。

您不必擔心目前 page_count 的碎片。

請閱讀以下來自 Paul Randal 的博文：

Books Online 索引碎片門檻值來自哪裡？

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