SharePoint Server 2016 和 2019 的軟體界限及限制
適用於：
Subscription Edition SharePoint in Microsoft 365
本文說明 SharePoint Server 2016 和 2019 的軟體界限和限制，包括：
邊界： 設計無法超過的靜態限制
臨界值：可超過以配合特定需求的可設定限制。
支援的限制：已經預設為已測試值的可設定限制
注意事項
[!附註] 本文件中的容量規劃資訊可做為您規劃工作之準則。 這些資訊是依據 Microsoft 內部實際機器上測試所得之結果。 不過，您的結果可能會因所用設備及網站實作的功能而異。
了解 Microsoft 365 中的 SharePoint 限制。
界限與限制的概觀
本文包含協助您了解 SharePoint Server 2016 已測試的效能與容量限制，並提供限制與可接受效能的相關準則。 請使用本文中的資訊來判斷您計畫的部署是否在可接受的效能與容量限制內，並適當地在環境中設定限制。
本文提供的測試結果和指導方針適用於單一 SharePoint Server 伺服器陣列。 Adding servers to the installation might not increase the capacity limits of the objects that are listed in the tables in the Limits and boundaries section later in this article. 另一方面，新增伺服器電腦會增加伺服器陣列的輸送量，在使用許多物件時，要達成可接受的效能，這是必要的。 在某些情況下，解決方案中對於大量物件的需求可能需要伺服器陣列中有更多的伺服器。
有許多因素可能會影響指定環境中的效能，而且每個因素都可能會影響不同區域的效能。 本文中的一些測試結果和建議可能與環境中不存在的功能或使用者作業有關，因此不適用於您的解決方案。 只有完整的測試才能提供與您自己的環境相關的精確資料。
界限、臨界值與支援的限制
在 SharePoint Server 中，有一些依設計而無法超過的限制，以及設定為伺服器數位管理員可能變更之預設值的其他限制。 也有某些限制不是以可設定的值表示，例如每個 Web 應用程式的網站集合數目。
界限是設計上無法超過的絕對限制。 請務必瞭解這些限制，以確保在設計伺服器陣列時不會做出不正確的假設。
界限的範例是 10 GB (GB) 檔案大小限制;您無法設定 SharePoint Server 2016 來儲存大於 10 GB 的檔。 此界限是內建的絕對值，無法在設計上超過。
閾值是除非修改值，否則無法超過的預設值。 在某些情況下，您可以依據伺服器陣列設計的變動而超越閾值。 除了其他限制的有效值之外，請務必了解超過閾值可能會影響伺服器數位的效能。
某些臨界值的預設值可以超過，但最多只能到絕對最大值。 文件大小限制是一個很好的範例。 根據預設，默認檔大小閾值會設定為 2 GB (GB) ，但可以變更為支援 10 GB 的最大界限。
支援的限制會為指定參數定義已測試值。 這些限制的預設值是由測試所定義，並呈現出產品的已知限制。 超過支援的限制可能會造成意外的結果、效能大幅降低或是其他有害的影響。
某些支援的限制是預設設定為建議值的可設定參數，而其他支援的限制則與不可設定值所表示的參數有關。
有關支援限制的範例為每個伺服器陣列的網站集合數目。 支援的限制是每個 Web 應用程式在測試期間符合效能基準的最大網站集合數目。
請務必瞭解，本檔中提供的許多限制值都代表曲線中的一個點，描述資源負載增加，以及隨著值增加而導致效能降低。 因此，超過某些限制 (例如，每個 Web 應用程式的網站集合數目) 可能只會導致伺服器陣列效能些微降低。 不過，在大部分情況下，在或接近已建立的限制下操作並不是最佳做法，因為當伺服器數位的設計提供合理限制值的平衡時，最佳的效能和可靠性目標會達到可接受的效能和可靠性目標。
臨界值與支援的限制準則取決於效能。 換句話說，您可以超過限制的預設值，但是當您增加限制值時，伺服器陣列效能與其他限制的有效值可能會受到影響。 SharePoint Server 2016 中的許多限制都可以變更，但請務必瞭解變更指定的限制如何影響伺服器陣列的其他部分。
限制的建立方式
在 SharePoint Server 中，臨界值和支援的限制是透過測試和觀察伺服器數位行為，在負載增加到伺服器數位服務和作業達到其有效作業限制的點為止。 有些伺服器陣列服務與元件比其他的服務與元件可支援更高的負載，因此在某些情況下，您必須根據一些因素的平均值來指定限制值。
例如您必須觀察伺服器陣列在增加網站集合負載之後的行為，是否會造成某些功能出現無法接受的高度延遲，而其他功能仍在可接受的限制範圍內正常運作。 因此，指派給網站集合數目的最大值不是絕對值，而是根據預期的一組使用特性來計算，在大部分情況下，整體伺服器數位效能可在指定的限制下接受。
很明顯地，如果其他服務使用高於限制測試的界限參數來進行作業，將會降低其他服務的最大有效限制。 因此，請務必針對特定部署執行嚴格的容量管理和調整測試練習，以建立該環境的有效限制。
注意事項
我們不會描述本檔中用來驗證限制的硬體，因為限制是從多個伺服器陣列和環境收集而來。
圓形圖象徵
為了要了解硬體資源、負載及效能之間的關係，應該具體呈現所涉及的因素以及這些因素彼此互相影響的方式。
將伺服器陣列容量想像成一個圓形圖，後者的大小代表各種因素的彙總，而這些因素包括伺服器、CPU 及 RAM 等硬體資源、儲存容量、磁碟 IOP、網路頻寬及延遲等。 因此，圓形圖的大小與伺服器陣列的整體資源相關；新增資源 (例如伺服器陣列的伺服器) 會增加圓形圖的大小。
此餅圖分成代表來自各種來源之負載的配量：使用者要求、搜尋查詢、針對已安裝功能的作業、定時器作業和操作系統額外負荷。 每個區段都必須共用可用的伺服器數組資源。 如果一個配量的大小增加，其他配量的大小必須按比例減少。 例如，由於伺服器陣列上的負載不是靜態 (使用者要求，因此可能只會在一天的特定時間) ，因此配量的相對大小會持續變動。 不過，每個配量都必須維持所需的最小大小才能正常運作，而且由於每個配量所代表的函式是相互依存的，因此增加一個配量的大小可能會增加其他配量的負載，除了減少可供它們取用的資源之外。
設計伺服器陣列時使用這個象徵的目的，是要讓圓形圖足以容納每個圓形圖塊在尖峰負載下的必要大小。
現在請考量使用者要求比基準增加 100% 的案例。 假設其中大約有一半的要求是搜尋查詢，而另一半的要求則是編輯清單及文件。 雖然這項增加的負載會擠壓其他區塊，但某些伺服器陣列功能也必須增加工作負擔來予以補償。 Search Service 必須處理更多查詢 (大多由快取處理)，而某些查詢會傳遞到資料庫伺服器，這樣也增加了後者的負擔。 如果資料庫伺服器上的負載變得太大，磁碟佇列長度就會增加，進而增加所有其他要求的延遲。
限制與界限
本節列出可成為解決方案一部分的物件，並提供每種物件可接受的效能準則。 可接受的效能表示經過測試的系統可以支援該物件數目，但若未降低效能或降低相關限制的值，就無法超過該數目。 物件會同時依範圍和依功能列出。 提供限制資料以及加上附註，描述取得限制的條件以及可取得其他資訊的連結。
使用本文中的準則檢閱您的整體解決方案計畫。 如果您的解決方案計畫超過一或多個物件的建議準則，請執行下列一或多個動作：
評估此解決方案以確保其他區域獲得補償。
標幟這些區域，以利建立部署時進行測試與監視。
重新設計或分割解決方案，以確保您不會超過容量指導方針。
依階層的限制
本節提供依 SharePoint Server 2016 伺服器陣列之邏輯階層所排序的限制。
Web 應用程式限制
下表列出 Web 應用程式的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| Web 應用程式 |
每個伺服器陣列 20 個 |
支援 |
我們建議儘可能將 Web 應用程式的數目限制設為最大數量。 盡量建立其他已指定主機名稱的網站集合，而不是新增 Web 應用程式。 |
| 區域 |
每個 Web 應用程式 5 個 |
界限 |
伺服器陣列定義的區域數目會硬式編碼為 5。 區域包括「預設」、「內部網路」、「外部網路」、「網際網路」及「自訂」。 |
| 已指定主機名稱之網站集合的管理路徑 |
每個伺服器陣列 20 個 |
支援 |
已指定主機名稱之網站集合的管理路徑會在伺服器陣列等級上套用。 所建立的每個管理路徑皆可在任何 Web 應用程式中加以套用。 |
| 路徑型網站集合的管理路徑 |
每個 Web 應用程式 20 個 |
支援 |
系統會在網頁伺服器上快取管理路徑，並根據管理路徑清單使用 CPU 資源來處理傳入要求。 路徑型網站集合的管理路徑會在 Web 應用程式層級套用。 您可以針對每個 Web 應用程式建立不同的管理路徑組合。 每個 Web 應用程式若有超過 20 個的管理路徑，則每個要求都會造成網頁伺服器增加更多負載。 如果您計畫在指定的 Web 應用程式中使用超過二十個管理路徑，我們建議您測試可接受的系統效能。 |
| 解決方案快取大小 |
每個 Web 應用程式 300 MB |
臨界值 |
解決方案快取允許 InfoPath Forms Services 在快取中儲存解決方案，以便加速解決方案的擷取。 如果超過快取大小，會從磁碟擷取解決方案，這可能會使回應時間變慢。 若要設定解決方案快取的大小，請參閱＜Set-SPInfoPathFormsService＞。 |
SharePoint 伺服器的限制
下表列出伺服器陣列上網頁伺服器的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 應用程式集區 |
每部網頁伺服器 10 個 |
臨界值 |
最大的數目是由硬體功能決定。 這個限制大部分取決於： 配置給網頁伺服器的記憶體數量 伺服器陣列所提供的工作量，也就是使用者群與使用特性 (單一高度活躍的應用程式集區可使用 10 GB 或更多) |
內容資料庫限制
下表列出內容資料庫的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 內容資料庫數目 |
每個伺服器陣列 500 個 |
支援 |
每個伺服器陣列的內容資料庫數目上限為 500。 每個 Web 應用程式有 500 個內容資料庫，開啟網站或網站集合等終端使用者作業不會受到影響。 但是建立新網站集合等管理作業的效能會降低。 若有大量的內容資料庫存在，我們建議您使用 PowerShell 來管理 Web 應用程式，因為管理介面可能會變慢且難以瀏覽。 SharePoint Server 2016 針對每個內容資料庫 200 GB，以及每個伺服器陣列 500 個內容資料庫支援每個伺服器數位 100 TB 的數據。 |
| 內容資料庫大小 (一般使用方式) |
每個內容資料庫 200GB |
支援 |
除非適用本表以下各列所述的情況，否則強烈建議將內容資料庫大小限制為 200 GB。 如果您使用遠端 BLOB 記憶體 (RBS) ，內容資料庫中遠端 BLOB 記憶體和元數據的總磁碟區不得超過 200 GB 的限制。 |
| 內容資料庫大小 (所有使用方式) |
每個內容資料庫 4 TB |
支援 |
如果符合下列需求，則可支援多達 4 TB 的內容資料庫： 每 GB 0.25 IOPS 的磁碟子系統效能。建議每 GB 2 個 IOP，以獲得最佳效能。 必須已經開發適合高可用性、嚴重損壞修復、未來容量及效能測試的計畫。 您也應該謹慎考量下列因素： 如果內容資料庫超過 200 GB，則其原生 SharePoint Server 2016 備份可能無法滿足備份與還原的需求。 建議您評估並測試 SharePoint Server 2016 備份和替代備份解決方案，以判斷您特定環境的最佳解決方案。 強烈建議您主動採用熟練的系統管理員管理 SharePoint Server 2016 和 SQL Server 安裝。 SharePoint Server 2016 複雜的自訂及設定動作，可能必須將資料重構 (或分割) 成多個內容資料庫。 請向熟練的專業結構設計師尋求建議並執行測試，以判定適合實作的最佳內容資料庫大小。 複雜性的範例可能包括自定義程式碼部署、在屬性升級中使用超過 20 個數據行，或是以下超過 4 TB 區段中列為不使用的功能。 重構網站集合可將 SharePoint Server 2016 實作擴充至多個內容資料庫。 這樣便可不受限制地調整 SharePoint Server 2016 實作。 如果內容資料庫小於 200 GB，重構就會更為輕鬆迅速。 建議您輕鬆備份和還原內容資料庫內的個別網站集合，限製為100 GB。 如需詳細資訊，請參閱＜ 網站集合限制＞。 重要事項：我們不建議使用超過 4 TB (TB 的內容資料庫) ，但在此表格) 的下一列所述的檔封存案例 (除外。 If, in the future, you need to upgrade your SharePoint Server 2016 installation, upgrading the site collections within the content databases can be very difficult and time consuming. > 強烈建議您跨多個內容資料庫相應放大，而不是在單一內容資料庫中超過 4 TB 的數據。 |
| 內容資料庫大小 (文件封存案例) |
內容資料庫沒有明確限制 |
支援 |
如果符合下列需求，則支援在文件封存案例中使用沒有明確大小限制的內容資料庫： 您必須滿足本表稍早的「內容資料庫大小 (所有使用方式)」限制中的所有需求，且必須確認已經謹慎考量該限制之「附註」欄位所討論的所有因素。 SharePoint Server 2016 網站必須以 文件中心或 記錄中心網站範本為基礎。 每月平均存取的內容資料庫內容低於 5%，且每月平均修改或寫入的內容低於 1%。 請勿在內容資料庫中的任何 SharePoint Server 2016 物件上使用警示、工作流程、連結修正或專案層級安全性。 > [!注意]> 檔封存內容資料庫可以設定為接受來自內容路由工作流程的檔。 |
| 內容資料庫項目 |
6 千萬個項目，包括文件及清單項目 |
支援 |
在 SharePoint Server 2016 上測試過的每個內容資料庫的項目最大數目是 6 千萬個，包括文件及清單項目。 如果您打算在 SharePoint Server 2016 中儲存超過 6 千萬個項目，則必須部署多個內容資料庫。 |
| 每個內容資料庫的網站集合 |
數目上限為 10,000 個 (2,500 個非個人網站集合和 7,500 個個人網站，或者只有 10,000 個個人網站) |
支援 |
我們強烈建議將內容資料庫中的網站集合數目限制為 5,000。 不過，最多可支援資料庫中有 10,000 個網站集合。 在網站集合總數高達 10,000 個的內容資料庫中，其中最多 2,500 個可以是非個人網站集合。 如果 10,000 個個人網站集合是內容資料庫內唯一的網站集合，則可以支持這些集合。 資料庫中網站集合數目的限制隸屬於具有多個網站集合的內容資料庫大小限制。 因此，當資料庫中的網站集合數目增加時，它所包含的網站集合平均大小就必須減少。 超過 5,000 個網站集合的限制，可能會讓您承擔升級期間停機時間增加的風險。 如果您計畫超過 5,000 個網站集合，我們建議您有明確的升級策略來處理中斷時間長度與對作業的影響，並取得其他硬體以加速會影響資料庫的軟體更新與升級。 Exceeding the 5,000 site collection limit puts you at risk of longer downtimes during upgrades. 如果您計畫超過 5,000 個網站集合，我們建議您有明確的升級策略來處理中斷時間長度與對作業的影響，並取得其他硬體以加速會影響資料庫的軟體更新與升級。 若要在內容資料庫中設定網站數目的警告與層級數目上限，請使用 PowerShell Cmdlet Set-SPContentDatabase 加上 WarningSiteCount 參數。 如需詳細資訊，請參閱＜ Set-SPContentDatabase＞。 |
| 網路連接儲存裝置 (NAS) 的遠端 BLOB 儲存區 (RBS) 儲存子系統 |
在 95% 的情況下，距離收到 NAS 任何回應之第一個位元組的時間應該保持在 40 毫秒內。 |
界限 |
當 SharePoint Server 2016 設定使用 RBS，且 BLOB 位於 NAS 儲存體時，請考慮下列支援限制。 從 SharePoint Server 2016 要求 BLOB 的時間開始，直到它從 NAS 收到第一個位元組為止，在 95% 的情況下不得超過 40 毫秒。 |
網站集合限制
下表列出網站集合的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 每個伺服器陣列的網站集合數 |
每個網站集合 250,000 個/500,000 個個人網站/每個伺服器陣列 250,000 個其他網站。 |
支援 |
每個伺服器陣列中網站集合的建議數目上限為 500,000 個個人網站加上 250,000 個適用於所有其他網站範本的網站。 網站可以全都位於同一個 Web 應用程式中，也可以分散於多個 Web 應用程式。 此限制會受到其他因素影響，這些因素可能會減少指定內容資料庫可支援的有效網站集合數目。 如果這些內容資料庫各包含 1,000 個網站集合，則 Web 應用程式中的網站集合總數就是 200,000 個，還是落在支援限制內。 不過，如果每個內容資料庫各包含 10,000 個網站集合，那麼，即使這個數目符合內容資料庫的支援限制，伺服器陣列中的網站集合總數卻會是 2,000,000 個，超過每個 Web 應用程式和每個伺服器陣列的網站集合數目限制。 例如，伺服器陣列 A 的 Web 應用程式含有 200 個內容資料庫，這是支援的設定。 如果這些內容資料庫各包含 1,000 個網站集合，則 Web 應用程式中的網站集合總數就是 200,000 個，還是落在支援限制內。 不過，如果每個內容資料庫包含10,000個網站集合，即使此數目支援內容資料庫，伺服器陣列中的網站集合總數為2,000,000，超過每個Web應用程式的網站集合數目限制。 網頁伺服器上的記憶體使用量應受到監視，因為記憶體使用量相依於使用模式以及可在特定時間範圍內存取的網站數目。 同樣地，編目目標也可能會展示記憶體壓力，而且，如果是此情況，則應在任何網頁伺服器上的可用記憶體降低到少於 2 GB 之前，將應用程式集區設定為回收使用。 |
| 網站 |
每個網站集合 250,000 個/每個伺服器陣列 250,000 個/每個伺服器陣列 500,000 個個人網站。 |
支援 |
雖然網站集合中支援的網站數目限制為 250,000 個，但建議的限制為 2,000 個。 在網站集合中，當網站的數目超過 2,000 個時，效能可能會降低。 重要事項：強烈建議每個網站集合保持低於 2,000 個網站。 您可以建立多個網站集合，每個網站集合最多 2000 個網站，以建立非常大量的網站總數。 例如，包含 2,000 個網站的 125 個網站集合，分別等於伺服器數位中的 250,000 個網站。 這會被視為非個人網站的最大建議限制。 如果您有 250,000 個網站集合，其中所有網站都包含不是個人網站範本的根網站，則將子網站新增至這些根網站中的任何一個將會超過 250,000 個網站界限。 如果超過每個網站集合建議的 2,000 個網站限制，可能會發生下列問題： 刪除或建立網站會顯著影響相同網站集合中其他網站的可用性。 在刪除網站時，對網站集合中網站的存取權會受到限制。 嘗試同時建立許多網站也可能會失敗。 有超過 2,000 個網站時，在將新伺服器新增至現有伺服陣列時或在安裝 SharePoint 更新之後執行 PSConfig 之類動作的效能將會大幅降低。 執行 stsadm -o checklocalupgradestatus 作業或每日執行產品版本工作計時器工作，可能要花好幾個小時才能完成。 流覽管理中心網站上 (<your_SharePoint_CentralAdmin_URL>/_admin/UpgradeStatus.aspx) 的 [檢閱資料庫狀態] 頁面可能會導致逾時。 |
| 網站集合大小 |
內容資料庫的大小上限 |
支援 |
A site collection can be as large as the content database size limit for the applicable usage scenario. For more information about the different content database size limits for specific usage scenarios, see the Content database limits table in this article. 一般而言，強烈建議將網站集合大小限制為 100 GB，原因如下： Certain site collection actions, such as site collection backup/restore or the PowerShell cmdlet Move-SPSite, cause large SQL Server operations which can affect performance or fail if other site collections are active in the same database. For more information, see Move-SPSite. 只有網站集合大小上限為 100 GB 時，才支援 SharePoint 網站集合備份和還原。 若為較大的網站集合，則必須備份整個內容資料庫。 如果單一內容資料庫包含多個大於 100 GB 的網站集合，則備份與還原作業可能需時甚久且有失敗的風險。 |
| 每個發佈網站集合的裝置通道數目 |
10 |
界限 |
每個發佈網站集合的裝置通道數目允許上限為 10。 |
清單與文件庫限制
下表列出清單和文件庫的建議準則。 如需詳細資訊，請參閱設計大型清單和最大化清單效能 (SharePoint Server 2010)。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 列出列大小 |
每列 8,000 個位元組 |
界限 |
Each list or library item can only occupy 8,000 bytes in total in the database. 300 bytes are reserved, leaving 7700 bytes for end-user columns. For details on how much space each kind of field consumes, see Column limits. |
| 檔案大小 |
10GB |
界限 |
預設檔案大小是 20 億位元組 (GB) (也就是 2,047MB)。 不過，大量的極大型檔案可能會影響伺服器陣列效能。 注意：在 SharePoint Server 2019 中，檔案的限制為 15 GB。 |
| 文件 |
每個文件庫 30,000,000 個 |
支援 |
您可以建立巢狀資料夾、使用標準檢視與網站階層，以建立龐大的文件庫。 這個值會隨組織文件與資料夾的方式而異。 |
| 主要版本 |
400,000 |
支援 |
如果超過這個限制，基本檔案作業 (例如檔案開啟或儲存、刪除和檢視版本歷程記錄) 可能不會成功。 |
| 次要版本 |
511 |
界限 |
次要檔案版本的數目上限為 511。 無法超過此限制。 |
| 項目 |
每個清單 30,000,000 個 |
支援 |
您可以使用標準檢視、網站階層及中繼資料瀏覽，建立龐大的清單。 這個值可能會隨清單中的欄數及清單的使用而異。 |
| 大量作業 |
每個大量作業 100 個項目 |
界限 |
使用者介面允許大量作業最多可選取 100 個項目。 |
| 清單檢視查閱臨界值 |
每個查詢有 12 個聯結作業 |
臨界值 |
Specifies the maximum number of joins allowed per query, such as those based on lookup, person/group, or workflow status columns. If the query uses more than eight joins, the operation is blocked. 這不適用於單一項目作業。 但是，如果使用以物件模型設定的最大檢視 (設定方式是不指定任何檢視欄位)，SharePoint 就會傳回前面 12 項查閱。 |
| 清單檢視臨界值 |
大於 5,000 |
臨界值 |
指定資料庫作業 (例如查詢) 在管理員設定的每日時間範圍之外，同時可處理的清單或文件庫項目數目上限。在管理員設定的每日時間範圍內，查詢將不受限制。 新增或移除欄索引時，臨界值預設為 20,000。 移除清單或資料夾時，臨界值預設為 100,000。 在相同資源庫中重新命名資料夾時，臨界值預設為 100,000。 |
| 稽核者及管理員的清單檢視臨界值 |
20,000 |
臨界值 |
指定當稽核員或系統管理員以適當許可權執行時，資料庫作業，例如查詢等可同時處理的清單或連結庫專案數目上限。 此項設定會配合 [允許物件模型覆寫] 運作。 |
| 子網站 |
每個網站檢視 2,000 個 |
臨界值 |
列舉指定網站子網站的介面效能不佳，因為子網站數目超過2,000個。 同樣地，[所有網站內容] 頁面與 [樹狀檢視控制項] 效能將會隨子網站數目成長而大幅降低。 |
| 清單 |
每個網站 2,000 個 |
臨界值 |
測試指出超過兩千個項目後清單檢視的效能會降低。 |
| 在 Word 與 PowerPoint 中共同撰寫 .docx, .pptx 與 .ppsx 檔案。 |
每份文件 10 個同時編輯者 |
臨界值 |
建議的同時編輯者最大數目為 10。 界限為 99。 如果有 99 位共同作者開啟單一文件同時編輯，則每位後續的使用者都會看到「檔案使用中」錯誤，而且只能開啟唯讀複本。 超過 10 位共同編輯者將導致更多衝突且效能逐漸降低的使用者經驗，而且使用者可能必須重複執行更多次，才能將其變更上傳成功到伺服器。 |
| 安全性範圍 |
每個清單 50,000 個 |
臨界值 |
為清單設定的唯一安全性範圍數目上限不能超過50,000個。 針對大部分的伺服器陣列，建議您考慮將此限制降低至 5,000 個唯一範圍。 針對大型清單，請考慮使用唯一權限數儘可能最少的設計。 當清單的唯一安全性範圍數目超過清單檢視臨界值 (預設為 5,000 個清單項目) 時，則在檢視清單時，會執行其他的 SQL Server 來回動作，這會對清單檢視效能產生負面影響。 範圍是安全性實體物件及其任何未定義個別安全性界限之子系的安全性界限。 範圍包含存取控制清單 (ACL)，但是與 NTFS ACL 不同的是，範圍可以包括 SharePoint Server 2016 特有的安全性主體。 範圍的 ACL 成員可以包括 Windows 使用者、非 Windows 使用者的使用者帳戶 (例如，表單型帳戶)、Active Directory 群組或 SharePoint 群組。 |
| 安全性範圍 (ACL) 傳播 |
具有唯一範圍的 500 個子物件 |
臨界值 |
具有可在 ACL 傳播期間更新之唯一安全性範圍的子物件數目上限不能超過 500 個。 可以使用 ACL 傳播將範圍更新設定為更新子物件，這樣就會更新唯一限定範圍的項目，和繼承權限的項目。 在更新包含 ACL 傳播的父範圍期間，如果具有唯一範圍的子物件最大數目大於 500，傳播就會失敗，而只會更新部分可能會更新唯一範圍的子範圍。 每當具有唯一範圍的子物件數目上限大於 500 時，就不應該使用 ACL 傳播。 |
欄限制
SharePoint Server 2016 資料儲存在 SQL Server 資料表中。 每個欄類型都有以位元組為單位的大小值。 SharePoint 清單中所有數據行的總和不能超過8,000個字節。
| 限制 | 欄數上限 | 限制類型 | 每欄的大小 | 附註 |
|---|---|---|---|---|
| 單行文字 |
255 |
臨界值 |
30 個位元組 |
|
| 多行文字 |
350 |
臨界值 |
22 個位元組 |
|
| 選擇 |
255 |
臨界值 |
30 個位元組 |
|
| 選擇 (多個選取專案) |
350 |
臨界值 |
22 個位元組 |
|
| 數字 |
550 |
臨界值 |
14 個位元組 |
|
| 貨幣 |
550 |
臨界值 |
14 個位元組 |
|
| 日期及時間 |
550 |
臨界值 |
14 個位元組 |
|
| 查閱 |
750 |
臨界值 |
10 個位元組 |
|
| 是/否 |
1000 |
臨界值 |
7 個位元組 |
|
| 個人或群組 |
750 |
臨界值 |
10 個位元組 |
|
| 超連結或圖片 |
127 |
臨界值 |
60 個位元組 |
超連結或圖片欄配置了兩欄的儲存空間：一個用於 URL、一個用於描述。 |
| 計算 |
255 |
臨界值 |
30 個位元組 |
SQL Server 資料列換行會發生在 SharePoint 清單中每八個數據行一次之後。 預設列換行值 6 允許每個 SharePoint 清單有 48 個 [計算] 欄的最大值 (6 * 8 = 48)。 |
| GUID |
350 |
臨界值 |
22 個位元組 |
SQL Server 列換行會發生在 SharePoint 清單中每欄的後面。 預設列換行值 6 允許每個 SharePoint 清單有 6 個 [GUID] 欄的最大值 (6 * 1 = 6)。 |
| 整數 |
750 |
臨界值 |
10 個位元組 |
|
| 受管理的中繼資料 |
190 |
臨界值 |
第一個為 60 個位元組，之後的每個則為 40 個位元組 |
新增至清單的第一個 [受管理的中繼資料] 會配置 4 欄： 實際標記的查閱欄位 字串值的隱藏文字欄位 全部擷取的查閱欄位 全部擷取的溢出查閱欄位 每個新增至清單的後續 [受管理的中繼資料] 欄位會再新增兩個欄： 實際標記的查閱欄位 字串值的隱藏文字欄位 受控元數據的數據行數目上限計算為 (14 + (16 * (n-1) ) ) ，其中 n 是數據列對應值 (預設值 6) 。 |
| 地理位置 |
2 |
臨界值 |
30 個位元組 |
[外部資料] 欄具有主要欄與次要欄的概念。 當您新增外部資料欄時，可以選取要新增至清單中之外部內容類型的一些次要欄位。 例如，假設外部內容類型為 「Customer」，其字段包括 「ID」、“Name”、“Country” 和 “Description”，當您將類型為 “Customer” 的 [外部數據] 資料行新增至清單時，您可以新增次要字段來顯示客戶的 [標識符]、[名稱] 和 [描述]。 整體而言，這些是新增的欄：
主要欄：文字欄位。
隱藏標識碼數據行：多行文字欄位。
次要欄：每個次要欄都是文字/數字/布林值/多行文字，這個文字是以「商務資料目錄」模型中所定義之次要欄的資料類型為基礎。 例如，[識別碼] 可能會對應至 [數字] 欄；[名稱] 可能會對應至 [單行文字欄]；[說明] 可能會對應至 [多行文字] 欄。
頁面限制
下表列出頁面的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 網頁組件 |
每個 Wiki 或網頁組件頁面 25 個 |
臨界值 |
This figure is an estimate based on simple Web Parts. 網頁組件的複雜度會規定頁面上可以使用多少個網頁組件，才不會影響效能。 |
安全性限制
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 使用者可以隸屬的 SharePoint 群組數目 |
5,000 |
支援 |
這不是硬性限制，但與Active Directory指導方針一致。 以下是影響此數字的一些事項： 使用者 Token 的大小 群組快取：SharePoint Server 2016 有一個表格，當使用者所屬的群組用於存取控制清單 (ACL) 時，此表格快取這些群組的數目。 安全性檢查時間：隨著使用者為隸屬成員的群組數目增加，存取檢查所需的時間也會增加。 |
| 網站集合中的使用者 |
每個網站集合 2 百萬 |
支援 |
您可以使用 Microsoft Windows 安全性群組來管理安全性，而非使用個別使用者，將數百萬的人員新增至網站。 這個限制是根據使用者介面的易用性與瀏覽的舒適度而定。 在網站集合 (超過一千個) 中有多個實體 (使用者的安全性群組) 時，您應該使用PowerShell 來管理使用者而非 UI。 此方式可以提供較佳的管理經驗。 |
| 在 SharePoint 群組中的 Active Directory 原則/使用者 |
每個 SharePoint 群組 5,000 個 |
支援 |
SharePoint Server 2016 可讓您將使用者或 Active Directory 群組新增至 SharePoint 群組。 在 SharePoint 群組中最多可擁有 5,000 個使用者 (或 Active Directory 群組或使用者)，在此數目下仍能提供可接受的效能。 受到此限制影響最多的活動如下： 擷取使用者以驗證權限。 這個作業會隨著群組中的使用者數目成長而逐漸需要更久的時間。 顯示檢視的成員資格。 這個作業永遠都需要時間。 |
| SharePoint 群組 |
每個網站集合 10,000 個 |
支援 |
10,000 個以上的群組，執行作業的時間會大幅增加。 特別是將使用者新增至現有群組、建立新群組以及呈現群組檢視。 |
| 安全性主體：安全性範圍的大小 |
每個存取控制清單 (ACL) 5,000 個 |
支援 |
The size of the scope affects the data that is used for a security check calculation. This calculation occurs every time that the scope changes. 沒有硬性限制，但範圍越大，計算所花費的時間就會越長。 |
依功能的限制
這個區段會列出依功能排序的限制。
搜尋限制
建議的搜尋準則是依搜尋所影響的各層面組織：拓撲、項目大小、字典、編目、結構描述、查詢和結果、排名及索引。
搜尋: 拓撲限制
拓撲限制可確保搜尋元件之間進行有效率的通訊。 Exceeding these limits slows down the communication between search components, which can result in longer query latencies and ultimately outage of search.
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 分析處理元件 |
每個 Search Service 應用程式 6 個；每部伺服器 1 個 |
支援 |
|
| 分析報告資料庫 |
每個 Search Service 應用程式 4 個 |
臨界值 |
您可以超過此限制，以配合特定需求。 進行調整時，當任何已部署分析資料庫的大小達到總大小 250 GB 或總計 2000 萬個數據列時，請新增分析報告資料庫。 如此一來，重新分割就能盡量維持平衡。 |
| 連結資料庫 |
每個 Search Service 應用程式 4 個 |
支援 |
連結資料庫可以包含的最高測試項目數目是 1 億個。 |
| 編目元件 |
每個 Search Service 應用程式 16 個；每部伺服器 1 個 |
支援 |
|
| 索引元件 |
每個 Search Service 應用程式 60 個；每部伺服器 4 個 |
支援 |
若要計算您有的索引元件數目，請將索引分割區數目乘以索引複本數目。 |
| 索引分割區 |
每個 Search Service 應用程式 25 個 |
支援 |
索引分割區具有 Search Service 應用程式索引的子集。 增加索引分割區的數目會導致每個分割區的索引子集較小，從而減少主控索引元件的伺服器所需的 RAM 與磁碟空間。 |
| 索引複本 |
每個索引分割區 3 個 |
支援 |
每個索引分割區可以有一組複本。 如果您增加索引複本數目，將會對查詢效能產生正面影響，且可提供更佳的容錯。 但是，如果在索引分割區中新增太多複本，則會對索引編製產生負面影響。 對於網際網路網站案例 (通常具有高查詢率和低內容量，即每個分割區少於 4 百萬個項目)，則支援的限制為每個分割區 6 個索引複本。 |
| 內容處理元件 |
每部伺服器 1 個 |
支援 |
搜尋拓撲可支援將內容處理元件數目向外延伸。 雖然特定的實體主機或虛擬機器並不支援多個內容處理元件，但使用一個內容處理元件還是能夠達到更佳的 CPU 容量使用率。 原因在於有個內建機制可以依照可用的 CPU 核心來調整饋送工作階段數目，藉以將 CPU 使用量最大化。 多個饋送工作階段可讓內容處理元件平行處理傳入的文件。 此機制假設每部主機都有單一內容處理元件。 如果主機上的實體核心數目等於 N，則內容處理元件會有 NK 饋送會話。K 是具有初始值 3 的常數係數。4 核心伺服器有12個饋送會話，這表示內容處理元件可以平行處理12份檔。您可以藉由設定 Search Service 應用程式的 NumberOfCssFeedersPerCPUForRegularCrawl 屬性來變更 K 的值。SharePoint Server 2016 會將 N 的值向上限制為 12，即使伺服器有超過 12 個實體核心也一般。因此，16 核心伺服器具有 NK = 12 * 3 = 36 個饋送會話。 如果仍然會有閒置的 CPU 時間，請考量提高 K 係數，而不是新增額外的內容處理元件。 如果您提高 K 係數，就必須確定主機擁有足夠的可用記憶體。 |
| 查詢處理元件 |
每部伺服器 1 個 |
支援 |
SharePoint Server 2016 支援每個實體機器或虛擬機器上只有一個查詢處理元件。 |
| 搜尋元件 |
每個 Search Service 應用程式 64 個 |
支援 |
此限制不包含編目元件。 其他的搜尋元件數的總和必須保持在這個限制內。 |
| Search Service 應用程式 |
每個伺服器陣列 20 個 |
支援 |
在相同的伺服器陣列上可以部署多個 Search Service 應用程式，因為您可以將搜尋元件與資料庫指派到不同的伺服器。 此限制小於伺服器陣列中服務應用程式總數的限制。 |
| 內容來源 |
每個 Search Service 應用程式 500 個 |
界限 |
每個內容來源都有相關聯的額外負荷，因此建議您建立符合其他作業需求的最小內容來源數目，例如編目優先順序和排程的差異。 |
搜尋: 項目大小限制
項目大小限制可保護編目效能和索引的大小。 以下是這些限制可如何影響搜尋的一些範例：
如果當您搜尋項目時無法取得結果，項目可能太大。 編目記錄檔中會顯示警告，指出檔案超過編目程式可以下載的大小上限。
If you search for text in an item and only get results from the first part of the text, the content processing component may have truncated the item because it exceeded some of item size limits. When the content processing component truncates an item, it indicates this by setting the managed property IsPartiallyProcessed to True. A warning will also show up in the Crawl Log, stating why the item was truncated.
如果您要調整項目大小限制，建議您依下表中的順序，依序進行處理。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 編目元件可以下載的文件大小 |
Excel 檔的 64 MB (4 MB) |
臨界值 |
搜尋會下載文件的中繼資料與內容，直到到達最大文件大小為止。 其餘內容不會下載。 搜尋一律會下載文件的中繼資料。 You can change the default limit for the maximum document size. Do this by using Microsoft PowerShell cmdlets to change the Search service application property MaxDownLoadSize or MaxDownloadSizeExcel. MaxDownLoadSize doesn't impact the maximum size for Excel documents. Enter the value in megabytes. The maximum value for the maximum document size is 1024 MB, also for Excel documents. 如果您增加最大文件大小的限制，搜尋會索引更多的內容，並需要更多磁碟空間。 |
| 剖析的內容大小 |
200 萬個字元 |
界限 |
搜尋在剖析項目的內容 (包括項目的附件) 最多達 200 萬個字元之後，就會停止剖析項目。 實際剖析的字元數可能低於此限制，因為搜尋在剖析單一專案及其附件時最多會使用 30 秒。 搜尋停止剖析項目時，會將項目標示為已部分處理。 任何未剖析的內容皆不會受到處理，因此不會編到索引中。 |
| 斷詞工具所產生的字元 |
1,000,000 |
界限 |
搜尋會將內容斷成個別字詞 (語彙基元)。 斷詞工具可從單一項目 (包括項目的附件) 的前 1,000,000 個字元產生語彙基元。 實際處理的項目數可能低於此限制，因為搜尋會在斷詞時使用最多 30 秒。 不會處理任何剩餘的內容，因此不會編製索引。 |
| 編製索引的 Managed 屬性大小 |
每個可搜尋/可查詢的 Managed 屬性 512 KB |
臨界值 |
此限制類型是設定為「可搜尋」或「可查詢」之 Managed 屬性大小上限的預設值。 You can configure this limit by using PowerShell cmdlets and the schema object model to set the MP.MaxCharactersInPropertyStoreIndex attribute. 輸入值 (以位元組為單位)。 此上限值的可設定的最大值為 2097152 位元組。 如果您增加此限制，您可以針對每個 Managed 屬性啟用更多數據的索引編製。 每個 Managed 屬性編製更多資料的索引會使用更多的磁碟空間，並增加搜尋系統上的整體負荷。 |
| 可擷取的 Managed 屬性大小 |
每個 Managed 屬性 16 KB |
臨界值 |
此限制類型是可擷取之 Managed 屬性大小上限的預設值。 如果您增加此限制，您可以針對每個 Managed 屬性啟用更多數據的索引編製。 提高此限制也會讓搜尋從每個 Managed 屬性擷取更多資料做為搜尋結果。 讓每個 Managed 屬性都有更多資料可被編到索引和擷取，將會增加系統整體負載，並佔用更多磁碟空間。 您可以使用 PowerShell Cmdlet 和結構描述物件模型來設定 P.MaxCharactersInPropertyStoreForRetrieval 屬性，藉以設定每個 Managed 的此限制。 輸入值的單位是位元組。 此上限值的可設定的最大值為 2097152 位元組。 如果您增加此限制，您可以針對每個 Managed 屬性啟用更多數據的索引編製。 增加此限制，搜尋也可以讓每個 Managed 屬性擷取更多的資料，以取得搜尋結果。 每個 Managed 屬性檢索和擷取更多資料 |
| 可排序和可精簡搜尋的 Managed 屬性大小 |
每個 Managed 屬性 16 KB |
界限 |
此限制類型是可排序和可精簡的 Managed 屬性的大小上限。 |
| 語彙基元大小 |
變數 |
界限 |
搜尋可以將任何長度的語彙基元編到索引中。 但是搜尋用來產生語彙基元的斷詞工具可能會限制語彙基元長度。 斷詞工具是一種會將內容斷成單一字詞 (語彙基元) 的語言感知元件。 您也可以建立自訂斷詞工具。 因此，語彙基元大小限制會取決於斷詞工具。 以下是西方語言的斷詞工具限制： 斷詞工具只會考慮語彙基元的前 1000 個字元來進行分割，它會忽略其餘的字元。 斷詞工具會將超過 300 個字元的語彙基元分割為兩個以上不超過 300 個字元的語彙基元。 例如，612 個字元的語彙基元會分割成兩個 300 個字元的語彙基元和一個 12 個字元的語彙基元。 |
| 每個 Managed 屬性的唯一索引語彙基元 |
1,000,000 |
臨界值 |
此限制類型是每個 Managed 屬性可新增至搜尋索引之唯一語彙基元數目的上限。 您無法對該限制進行變更。 如果超過限制，索引會包含來自 Managed 屬性的前 1,000,000 個令牌，並將 IsPartiallyProcessed 屬性設定為 true，將檔案標示為部分處理。 例外情況：如果已達到 ACL 相關 Managed 屬性的上限，則不會將該 Managed 屬性中的任何語彙基元新增至索引。 |
| 有權存取項目的相異使用者或 AD 安全性群組 |
1,000,000 |
臨界值 |
當超過 1,000,000 個相異的使用者或 AD 安全性群組能夠存取某個項目時，任何使用者都無法搜尋到該項目。 這類項目只會透過安全性與合規性中心，作為電子文件探索查詢的一部分傳回。 |
搜尋：字典限制
字典限制可保護記憶體、內容處理效率和查詢結果。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 同義字中的項目數 |
1 百萬 |
支援 |
同義字包含查詢字詞的同義字。 超過此已測試的限制可能會導致記憶體使用量增加以及查詢回應時間增加。 |
| 自訂實體擷取字典中的項目數 |
1 百萬 |
支援 |
超過此已測試的限制可能會導致記憶體使用量增加、索引速度變慢，且查詢回應時間增加。 |
| 自訂搜尋字典中的項目數 |
每個租用戶 5,000 個字詞 |
界限 |
此限制類型會限制允許包含和排除字典的字詞數目，以進行查詢拼字校正和公司擷取。 您可以在 Termstore 中儲存超過這個限制的字詞，但是搜尋只會針對每個租用戶使用 5000 個字詞。 |
搜尋：結構描述限制
結構描述限制可保護記憶體資源，並將管理作業負荷量保持在可接受的層級。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 編目屬性 |
每個 Search Service 應用程式 500,000 個 |
支援 |
編目項目的內容和中繼資料是以編目屬性來表示。 您可以將這些編目屬性對應到 Managed 屬性。 如果編目屬性的數目超過此支援的限制，索引編製速度就會降低。 |
| Managed 屬性 |
每個 Search Service 應用程式 50,000 個 |
支援 |
搜尋會在查詢中使用 Managed 屬性。 編目屬性會對應至 Managed 屬性。 超過 Managed 屬性的支援限制時，就會降低索引編製速度。 |
| Managed 屬性對應 |
每個 Managed 屬性 100 個 |
支援 |
編目屬性可對應至 Managed 屬性。 超過此限制可能會降低編目速度和查詢效能。 |
| 每個 Managed 屬性的值 |
1,000 |
界限 |
Managed 屬性可擁有多個相同類型的值。 此限制類型是每個檔每個受控多重值 Managed 屬性的最大值數目。 如果超過此數目，就會捨棄其餘值。 |
| 已辨識中繼資料屬性 |
每個已編目的項目 100,000 個 |
支援 |
此限制類型是編目元件在編目專案時可判斷的最大元數據屬性數目。 These metadata properties can be mapped or used for queries. 如果已編目的屬性太接近此數目，可能會使編目速率變很低。 |
搜尋：編目限制
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 起始位址 |
每個內容來源 500 個 |
支援 |
|
| 機器主機名稱的長度 |
15 個字元 |
臨界值 |
NetBIOS 會將機器主機名稱的最大長度限制在此值。 |
| 編目資料庫 |
每個 Search Service 應用程式 15 個 |
支援 |
搜尋：查詢與結果限制
查詢和結果的限制可保護搜尋引擎不執行大型查詢表達式並傳回大型結果集。 防止搜尋引擎執行大型查詢表達式並傳回大型結果集，可防止拒絕服務 (DoS) 攻擊，並確保結果會及時傳回。 如果您必須擷取更多結果，建議您使用分頁。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 使用關鍵字查詢語言時的查詢文字長度 |
4 KB (4096 個字元) |
支援 |
此限制類型是使用關鍵詞查詢語言所建置之查詢的文字長度上限和預設值，但探索查詢除外。 對於「探索」查詢，預設最大值是 16 KB (16384 個字元)。 500 列 |
| SharePoint 首頁上查詢的文字長度 |
16 KB (16,384 個字元) |
支援 |
此限制僅適用於 SharePoint Server 2019 公開預覽。 此限制類型是 SharePoint 首頁上所使用查詢文字長度上限的測試和預設值。 文字長度上限的預設值可以增加達到 20 KB (20,480) 的界限。 |
| 支援 |
500 列 |
支援 |
此限制類型是結果集中數據列數目上限的測試和預設值，但探索查詢除外。 對於「探索」查詢，預設值是 10000 列。 若要顯示整個結果集，請發出更多分頁查詢。 You can change the value for the maximum number of rows in a result set by using PowerShell cmdlets to change the Search service application property MaxRowLimit. MaxRowLimit defines the maximum value of the query property RowLimit and the Discovery query property RowLimit. RowLimit defines the number of rows each page contains in a result set. You can increase MaxRowLimit up to 10,000 rows, this is the supported boundary. |
| 結果移除 |
無限制 |
支援 |
|
| 搜尋提醒配額 |
每個 Search Service 應用程式 100,000 個提醒 |
支援 |
終端用戶可以設定查詢結果集的搜尋警示。 當結果變更或更新時，搜尋會通知使用者。 此限制類型是搜尋服務應用程式的測試限制，其用戶查詢混合 (75%) ，而警示查詢 (25%) 。 對於僅有提醒查詢的 Search Service 應用程式，此限制為 400,000 個提醒。 這些限制都是以每秒 5 個查詢 (QPS) 的系統為基礎。 |
搜尋：排名限制
排名限制可保護應用程式伺服器記憶體、查詢延遲，以及索引的大小。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 排名模型 |
每個租用戶 1,000 個 |
界限 |
太接近此限制可能會對整體系統效能產生負面影響。 |
| 用於排名的唯一內容 |
每個排名模型 15 個唯一內容 |
界限 |
此限制類型是每個排名模型中唯一內容的最大數目。 |
| 代表性頁面 |
每個 Search Service 應用程式一個最上層頁面和最少的第二層與第三層頁面 |
支援 |
在仍能達成所需相關性的限度下，盡可能少用第二與第三層頁面。 界限是每個 Search Service 應用程式每個相關性層級 200 個代表性頁面。 如果您新增更多頁面，可能達不到所需的相關性。 請將關鍵網站新增至第一個相關性層級。 將更多關鍵網站新增至第二個或第三個相關性層級，一次新增一個。 每新增一次後就評估一次相關性，以確保達到所需的相關性效果。 |
搜尋：索引限制
索引限制可保護索引不會成長到超出範圍，也不會超過可用的資源。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 索引中唯一的字詞 |
2^31 (>20 億個字詞) |
界限 |
此限制類型是 Search Service 應用程式的索引中可存在的唯一字詞最大數目。 |
| 使用者定義的全文檢索索引 |
10 |
界限 |
此限制類型是全文檢索索引的最大數目。 |
| 編製索引的項目 |
每個索引分割區 2 千萬個 |
支援 |
在 SharePoint Foundation 2013 中，套用 2016 年六月的公開更新之前，每個索引分割的索引項目數目上限是 200 萬。 如果索引項的數目與伺服器擁有的記憶體數量有關，則此取消分配會對查詢回應時間造成負面影響。 |
User Profile Service 限制
下表列出 User Profile Service 的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 使用者設定檔 |
每個服務應用程式 2,000,000 個 |
支援 |
User Profile Service 應用程式最多可支援 2 百萬個具有完整社交功能的使用者設定檔。 這個數目代表可以從目錄服務匯入人員設定檔儲存的設定檔數目，而且也是 User Profile Service 應用程式在不會導致社交功能效能降低的情況下，可支援的設定檔數目。 |
| 社交標籤、記事與評等 |
每個社交資料庫 500,000,000 個 |
支援 |
社交資料庫最多可支援 5 億個社交標記、記事和評等，而不會大幅降低效能。 不過，像備份與還原等資料庫維護作業可能會在執行時顯現出效能降低。 |
內容部署限制
下表列出內容部署的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 在不同路徑上執行的內容部署工作 |
20 |
支援 |
針對在連線到相同來源內容資料庫中網站集合的路徑上同時執行的工作，資料庫上發生死結的風險會增加。 For jobs that must run concurrently, we recommend that you move the site collections into different source content databases. 注意：無法在相同路徑上同時執行作業。 如果您使用 SQL Server 快照集進行內容部署，則每個路徑都會建立快照集。 此快照集路徑相互關聯會增加源資料庫的 I/O 需求。 如需詳細資訊，請參閱＜關於部署路徑與工作＞。 |
部落格限制
下表列出部落格的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 部落格文章 |
每個網站 5,000 個 |
支援 |
部落格文章數目上限為每個網站 5,000 篇。 |
| 註解 |
每篇文章 1,000 個 |
支援 |
每篇文章的註解數目上限為 1,000。 |
Business Connectivity Services 限制
下表列出 Business Connectivity Services 的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| ECT (記憶體中) |
每部網頁伺服器 (每個承租戶) 5,000 個 |
界限 |
在網頁伺服器上的指定時間點於記憶體中載入的外部內容類型 (ECT) 定義的總數。 |
| 外部系統連線 |
每部網頁伺服器 500 個 |
界限 |
指定時間點的作用中/開啟外部系統連線數目。 預設最大值為 200;界限為 500。 不論資料庫、.NET 元件等外部系統 (類型為何，都會在 Web 伺服器範圍強制執行此限制) 預設上限是用來限制連線數目。 應用程式可以透過執行內容指定較大的限制;界限會強制執行最大值，即使是不遵守預設值的應用程式也一樣。 |
| 每個要求傳回的資料庫項目 |
每個資料庫連接器 2,000 個 |
臨界值 |
每個要求資料庫連接器可以傳回的項目數目。 資料庫連接器會使用預設最大值 2,000 來限制每個頁面可傳回的結果數目。 應用程式可以透過執行內容指定較大的限制;絕對最大值會強制執行最大值，即使是不遵守預設值的應用程式也一樣。 此限制的界限為 1,000,000。 |
| 回應延遲 |
600 秒 |
臨界值 |
每個要求中外部資料連接器所使用的逾時。 預設值為 180 秒，但是可以設定應用程式，以指定更大的值 (最大值為 600 秒)。 |
| 服務回應大小 |
150,000,000 個位元組 |
臨界值 |
每個要求中外部資料連接器可傳回的上層資料數量。 預設值為 3,000,000 個位元組，但是可以設定應用程式，以指定更大的值 (最大值為 150,000,000 個位元組)。 |
| 篩選描述元 (在存放區) |
每個 ECT 方法 200 個 |
界限 |
每個 ECT 方法中篩選描述元的數目上限為 200 個。 |
| ECT 識別碼 (在存放區) |
每個 ECT 20 個 |
界限 |
每個 ECT 中識別碼的數目上限為 20 個。 |
| 資料庫項目 |
每個要求 1,000,000 個 |
臨界值 |
每個要求中資料庫連接器可傳回的預設項目數上限為 2,000 個，而絕對上限為 1,000,000 個。 The default max is used by the database connector to restrict the number of results that can be returned per page. 應用程式可以透過執行內容指定較大的限制;絕對最大值會強制執行允許的最大值，即使是不遵守預設值的應用程式，例如索引編製。 |
工作流程限制
下表列出工作流程的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 工作流程延遲臨界值 |
15 |
臨界值 |
15 is the maximum number of workflows allowed to be executing against a content database at the same time, excluding instances that are running in the timer service. 達到此臨界值時，啟動工作流程的新要求會排入佇列，以便稍後由工作流程定時器服務執行。 當非定時器執行完成時，新的要求會計入此臨界值。 您可以使用 Set-SPFarmConfig PowerShell Cmdlet 來設定此限制。 For more information, see Set-SPFarmConfig. 注意：此限制不是指可進行中的工作流程實例總數。 而是正在處理的實例數目。 增加這個限制會增加開始和完成工作流程工作的輸送量，但是也會增加針對內容資料庫與系統資源的負載。 |
| 工作流程計時器批次大小 |
100 |
臨界值 |
每次執行工作流程計時器工作時，將收集和傳送至工作流程的事件數目。 您可以使用 PowerShell 進行設定。 若要允許更多事件，您可以執行更多 SharePoint Foundation 工作流程定時器服務的實例。 |
| 工作流程關聯 |
每個清單 100 個 |
支援 |
超過此限制會降低瀏覽器效能，因為已載入超過100個關聯及其狀態數據行的大量數據。 |
| 可大量建立或上傳以啟動工作流程執行個體的清單項目或文件 |
5,000 個項目 |
支援 |
已經過測試，確認在單一大量上傳中最多建立 5,000 個項目時，會針對項目建立期間的工作流程關聯處理所有工作流程啟用事件。 超過此限制就會導致初始工作流程逾時。 |
| 每個網站發佈的工作流程定義 |
每個網站 1,000 個 |
支援 |
每個網站上支援的發佈工作流程定義數目上限為 1,000 個。 |
| 每個網站的工作流程關聯總數 |
每個網站 1,799 個 |
界限 |
服務匯流排針對每個範圍最多支援 1,799 個訂閱。 這個最大值包含已發佈和取消發佈之關聯的總和。 |
| 工作流程定義 (xaml) 大小上限 |
5,120 KB |
界限 |
嘗試發佈超過大小限制的 xaml 檔案失敗。 |
| xaml (工作流程複雜性) 中工作流程子步驟的深度上限 |
121 個等級 |
界限 |
xaml 中節點深度的硬性限制為 125。 121 個等級的最大值可說明 SharePoint Designer 自動插入的預設活動 (階段、序列等)。 |
| 每部網頁伺服器上每秒啟用的工作流程執行個體 |
每秒 6 個 |
界限 |
測試已確認 SharePoint 網頁伺服器每秒最多可以啟用六個工作流程實例。 此數字是累加的，因此，可在伺服器陣列中擴充網頁伺服器的數目。 例如，兩部網頁伺服器每秒可以啟用12個工作流程實例，而三部網頁伺服器可以啟用18個。 |
| 每部伺服器上每秒可從 SharePoint 工作流程進行的其餘呼叫 |
每秒 60 個 |
支援 |
測試已確認 SharePoint Web 伺服器可以有效地處理 SharePoint 工作流程中每秒最多 60 個待用呼叫。 如果超過此磁碟區層級，建議您將額外負載平衡的 Web 伺服器新增至 SharePoint 伺服器陣列。 在測試中，針對單一 Web 伺服器每秒 120 個靜態呼叫會導致持續的 90-100% CPU 使用率。 在這兩部伺服器上，新增第二部 Web 伺服器可降低 30-40% 的 CPU 使用率。 新增第三部網頁伺服器，每秒可處理 180 個呼叫，且這三部伺服器上的 CPU 使用率為 30-40%，依此類推。 用於這項測試的伺服器是 Hyper-V 虛擬機，每個都有 16 個核心處理器和 24 GB RAM。 |
| 工作流程變數值大小 |
256 KB |
界限 |
可儲存於單一工作流程變數中的資料量上限為 256 KB。 超過此限制會導致工作流程實例終止。 |
| 對於未編製索引之欄位所進行的工作流程查閱的清單大小上限 |
每個清單檢視 5,000 個項目 |
臨界值 |
此限制為最大檢閱大小限制的結果。 超過此限制時，非系統管理使用者的工作流程查閱未編製索引的欄位會失敗。 在此臨界值中，必須針對此欄位建立索引，以便讓工作流程能夠成功地針對該欄位執行查閱。 |
| 自動啟動之工作流程關聯的清單大小上限 |
每個清單 1 千萬個項目 |
支援 |
測試已確認當清單大小成長至1百萬個專案時，自動啟動工作流程關聯的效能不會受到影響。 Because response time doesn't change as list size scales, the effective limit is the same as the maximum number of items in a non-workflow list. |
受管理的中繼資料字詞儲存區 (資料庫) 限制
下表列出受管理的中繼資料字詞儲存區的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 字詞儲存區中巢狀詞彙的層次數目上限 |
7 |
支援 |
在詞彙集中的字詞可用階層加以表示。 詞彙集可多達 7 層的詞彙 (父系字詞以及在其下方的 6 層巢狀)。 |
| 在字詞儲存區中詞彙集的數目上限 |
1,000 |
支援 |
在字詞儲存區中可儲存多達 1,000 個詞彙集。 |
| 在詞彙集中詞彙的數目上限 |
30,000 |
支援 |
30,000 是在詞彙集中詞彙的數目上限。 注意：相同字詞的額外標籤，例如同義字和翻譯，不會計為個別字詞。 |
| 在字詞儲存區中項目的總數 |
1,000,000 |
支援 |
項目是指詞彙或詞彙集。 字詞和字片語的數目總和不能超過1,000,000。 同一字詞的其他標籤，例如同義字和翻譯，不會計為個別字詞。 注意：您不能同時在字詞庫中同時擁有字片語數目上限和字詞數目上限。 |
| 變化標籤數目 |
每個字詞庫 209 個 |
支援 |
每個字詞庫中變化標籤的數目上限為 209。 |
| 受管理導覽字詞組中的字詞數 |
2,000 |
支援 |
受管理導覽字詞組中所支援的字詞數目上限為 2,000。 |
| 受管理導覽字詞組中的直屬子字詞數 |
300 |
支援 |
受管理導覽字詞組中所支援的直屬子字詞數目上限為 300 個。 |
Visio Services 限制
下表列出 SharePoint Server 2016 的 Visio Services 執行個體的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 臨界值 |
50 MB |
臨界值 |
Visio Services 具有可讓管理員變更 Visio 所處理之 Web 繪圖大小上限的組態設定。 較大的檔案大小有下列副作用： 減少每秒應用程式伺服器的要求。 增加 CPU 的使用量。 減少每秒應用程式伺服器的要求。 增加整體的延遲。 增加 SharePoint 伺服器陣列網路負載 |
| 臨界值 |
120 秒 |
臨界值 |
Visio Services 具有可讓管理員變更在資料重新整理後重新計算繪圖所需時間上限的組態設定。 較大的重新計算逾時會導致： 減少 CPU 與記憶體的可用性。 減少每秒應用程式的要求。 增加所有文件的平均延遲。 較小的重新計算逾時會導致： 降低圖表可顯示的複雜度。 增加每秒的要求。 減少所有文件的平均延遲。 |
| 臨界值 |
快取保留時間下限：0 至 24 小時 |
臨界值 |
快取保留時間下限會套用至資料連線的圖表。 它會決定可從快取移除的目前圖表的最時機。 將 [最小快取存留期] 設定為低值可降低輸送量並增加延遲，因為讓快取失效的頻率太常會強制 Visio 經常重新計算，並降低 CPU 和記憶體可用性。 |
| Visio Services 快取保留時間上限 (非資料連線的圖表) |
快取保留時間上限：0 到 24 小時 |
臨界值 |
快取保留時間上限會套用至非資料連線的圖表。 這個值會決定要將目前圖表保留在記憶體中的時間。 增加快取保留時間上限可減少經常要求之繪圖的延遲。 不過，將 [快取存留期上限] 設定為高值會增加延遲，並降低未快取專案的輸送量，因為已經在快取中的專案會耗用並減少可用的記憶體。 |
PerformancePoint Services 限制
下表列出 SharePoint Server 2016 中的 PerformancePoint 服務 的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 儲存格 |
Excel Services 資料來源的每個查詢 1,000,000 個 |
界限 |
呼叫 Excel Services 資料來源的 PerformancePoint 計分卡受限於每個查詢不得超過 1,000,000 個儲存格的限制。 |
| 欄與列 |
15 欄 x 60,000 列 |
臨界值 |
轉譯任何使用 Excel 活頁簿做為數據源的 PerformancePoint 儀錶板物件時，數據行和數據列的最大數目。 可以變更的列數將視欄數而定。 |
| 針對 SharePoint 清單的查詢 |
15 欄 x 5,000 列 |
支援 |
使用 SharePoint list 做為資料來源的任何 PerformancePoint 儀表板物件，在轉譯時的欄與列數目上限。 可以變更的列數將視欄數而定。 |
| 針對 SQL Server 資料來源的查詢 |
15 欄 x 20,000 列 |
支援 |
The maximum number of columns and row when rendering any PerformancePoint dashboard object that uses a SQL Server table data source. 可以變更的列數將視欄數而定。 |
Word Automation Services 限制
下表列出 Word Automation Services 的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 輸入檔案大小 |
512 MB |
界限 |
Word Automation Services 可以處理的檔案大小限制。 |
| 啟動轉換的頻率 (分鐘) |
1 分鐘 (建議) 臨界值 59 分鐘 (界限) |
臨界值 |
這個設定決定 Word Automation Services 計時器工作執行的頻率。 較少的數目可使計時器工作執行速度較快。 我們的測試顯示每分鐘執行此定時器作業一次最有用。 |
| 每個轉換程序要啟動的轉換數目 |
要啟動的轉換數目會影響 Word Automation Services 的輸送量。 |
臨界值 |
要啟動的轉換數目會影響 Word Automation Services 的輸送量。 如果這些值設定高於建議的層級，則某些轉換專案可能會開始間歇性地失敗，而且用戶權力可能會過期。 使用者權限會從啟動轉換工作的時間起算之 24 小時後到期。 |
| 轉換工作大小 |
100,000 個轉換項目 |
支援 |
轉換工作包括一或多個轉換項目，每個項目都代表 SharePoint 的單一輸出檔案要執行的單一轉換。 使用 ConversionJob.Start 方法) 啟動轉換作業 (時，轉換作業和所有轉換專案都會傳輸到將作業儲存在 Word Automation Services 資料庫中的應用程式伺服器。 大量的轉換專案會增加 Start 方法的運行時間，以及傳輸至應用程式伺服器的位元元組數目。 |
| 使用中轉換程序總計 |
N-1，其中 N 是每部應用程式伺服器的核心數目 |
臨界值 |
使用中轉換程序可能會耗用單一處理核心。 因此，客戶不應該執行比其應用程式伺服器中具有處理核心更多的轉換程式。 轉換計時器工作與其他 SharePoint 活動偶爾也需要使用一個處理核心。 建議您保留一個可用的核心供轉換計時器工作與 SharePoint 使用。 |
| Word Automation Services 資料庫大小 |
2 百萬個轉換項目 |
支援 |
Word Automation Services 會在其資料庫中維持一個持續的轉換項目佇列。 每個轉換要求會產生一或多個記錄。 Word Automation Services 不會自動從資料庫中刪除記錄，因此資料庫可以無限期地成長，而不需要維護。 系統管理員可以使用 PowerShell Cmdlet Remove-SPWordConversionServiceJobHistory 手動移除轉換作業記錄。 如需詳細資訊，請參閱 Remove-SPWordConversionServiceJobHistory。 |
機器翻譯服務限制
下表列出機器翻譯服務的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 二進位檔的輸入檔大小 |
每個檔案 524,288 KB |
臨界值 |
大於此限制的檔案需要花費過長的時間來進行傳輸和處理，會降低服務的輸送量。 |
| 文字檔的輸入檔大小 |
每個檔案 15,360 KB |
臨界值 |
大於此限制的檔案會包含太多要翻譯的文字，會降低服務的輸送量。 |
| Microsoft Word 文件的字元數上限 |
每份文件 10,000,000 個 |
臨界值 |
若文件所包含的字元大於此限制，就會包含太多要翻譯的文字，會降低服務的輸送量。 |
| 並行翻譯程序總數 |
5 |
臨界值 |
使用超過限制的進程不會增加輸送量，因為一次可以翻譯的文字數量有限制。 使用較多的程序會提高對於伺服器資源的需求。 |
| 翻譯間的延遲 |
59 分鐘 |
臨界值 |
以大於此限制的時間間隔來啟動翻譯，會導致用來翻譯文件的時間變得太長，而且會導致排入佇列的翻譯數目大幅成長。 |
| 每個翻譯程序的翻譯數目 |
每個程序 1,000 個 |
臨界值 |
啟動超過限制的翻譯會導致翻譯因為逾時而失敗，因為在逾時期間之前無法處理它們。 |
| 並行翻譯要求的數目上限 |
300 |
臨界值 |
若並行翻譯要求超過 300 個，就會導致翻譯逾時，原因在於要求排入佇列的時間會比逾時期間還要長。 |
| 每個翻譯工作的檔案數 |
100,000 個檔案 |
支援 |
提交所含檔案計數超過此限制的工作會導致工作提交時間和處理期間過長。 |
| 機器翻譯服務資料庫大小 |
1,000,000 個檔案 |
支援 |
如果資料庫成長超過資料庫中檔案數目的上限，維護工作佇列的操作速度就會變慢。 |
Office Online 服務限制
The following table lists the recommended guidelines for Office Online. Office client application limits also apply when an application is running as a web app.
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 快取大小 |
100 GB |
臨界值 |
建立在內容資料庫中且可供轉譯文件的空間。 根據預設，可供轉譯文件的快取為 100 GB。 我們不建議您增加可用的快取。 |
| 轉譯 |
每個應用程式伺服器每個 CPU 核心每秒每個文件一個 (最大 8 個核心) |
界限 |
在一段期間內在應用程式伺服器上可以為「一般」文件執行的測量轉譯平均數目。 |
| 臨界值 |
每份文件 8 個 |
臨界值 |
OneNote merges combine changes from multiple users who are co-authoring a notebook. 如果有太多並行合併已經在執行中，則會產生衝突頁面，強制使用者手動執行合併。 |
Project Server 限制
下表列出 Project Server 的建議準則。 如需如何計畫 Project Server 的詳細資訊，請參閱＜Planning and architecture for Project Server 2010＞。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 專案時間的結束 |
日期：2149/12/31 |
界限 |
項目計劃不能超過日期 12/31/2149。 |
| 每個專案計畫的可傳送作業 |
1,500 個可傳送作業 |
界限 |
項目計劃不能包含超過 1,500 個交付專案。 |
| 在檢視中的欄位數目 |
256 |
界限 |
使用者不能將超過 256 個字段新增至他們在 Project Web App 中定義的檢視。 |
| 檢視的篩選中子句的數目 |
50 |
界限 |
用戶無法將篩選新增至檢視中具有超過50個子句。 |
SharePoint 應用程式限制
下表列出 SharePoint 應用程式的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| Access/SharePoint 應用程式套件大小上限 |
100 MB |
界限 |
SQL Azure 中 Access 應用程式資料庫儲存空間的大小上限 > [!注意]> Access 會在建立應用程式套件時壓縮資料庫，因此應用程式套件可能包含超過 100 MB 的數據。 |
| SQL Azure 中 Access 應用程式資料庫儲存空間的大小上限 |
1 Gb |
界限 |
在 SharePoint 上建立的每個 Access 應用程式都會在 SQL Azure 上建立資料庫。 1 GB 是 SQL Azure 上資料庫儲存空間的限制。 在內部部署安裝中，系統管理員會控制相關聯 SQL 資料庫的大小。 |
| [管理授權] 頁面中顯示的應用程式數目 |
2,000 |
界限 |
最多可在 [管理授權] 頁面上顯示 2,000 個應用程式 (可從市集中購買)。 您仍然可以移至應用程式安裝所在之網站的 [所有網站內容] 頁面，然後按一下 [授權]，或者使用 [市集搜尋] 來搜尋應用程式，藉以管理所有應用程式的授權。 |
| 每個租用戶的應用程式授權數目 |
1,000,000 |
支援 |
在內部部署或 SharePoint Microsoft 365 中，從市集) 購買應用程式 (支援的授權數目上限。 超過此限制可能會導致嚴重的效能降級。 |
| [新增應用程式] 頁面中顯示的應用程式數目 |
240 |
界限 |
到達此限制之後，只會顯示前 240 個應用程式，並會顯示一則訊息引導您進行搜尋，以尋找要顯示的應用程式。 |
| 每個應用程式授權的管理員人數 |
30 |
界限 |
只有 30 個人可以管理一個授權。 授權管理員可以新增或移除使用者，或者刪除授權。 |
| 指派給使用者，讓該使用者可以檢視的應用程式授權數目 |
2,000 |
界限 |
將超過 2,000 個授權指派給使用者時，該使用者將不會再在預設的 [ 新增應用程式] 檢視 中看到任何應用程式。 而是會出現一則訊息，引導您搜尋應用程式目錄，也可能會出現 SharePoint 市集。 |
| 公司目錄中可供單一使用者檢視的應用程式數目 |
500 |
界限 |
當來自公司目錄的 500 個以上的應用程式可供單一使用者使用時，該使用者將不會再在預設的 [ 新增應用程式 ] 檢視中看到任何應用程式。 而是會出現一則訊息，引導您搜尋應用程式目錄，也可能會出現 SharePoint 市集。 |
分散式快取服務限制
下表列出分散式快取服務的建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 每部快取主機中可追蹤的實體數 (使用者、文件、網站及雜湊標記) |
400,000 |
支援 |
在已指派 16 GB RAM 給分散式快取服務的分散式快取主機上，可以接著單一使用者的實體總數為 400,000。 |
| 叢集中快取主機的數目 |
16 |
界限 |
單一分散式快取叢集可支援的快取主機總數為 16。 |
| 快取主機專屬的記憶體數量上限 |
16 GB |
界限 |
叢集中任一部快取主機上分散式快取服務專屬的記憶體總數為 16 GB。 |
其他限制
下表列出其他小節未涵蓋之服務與功能的限制與建議準則。
| 限制 | 最大值 | 限制類型 | 附註 |
|---|---|---|---|
| 每個裝置通道中使用者代理程式子字串的數目 |
150 |
界限 |
每個裝置通道中使用者代理程式子字串的最大數目為 150。 |
| 每個 eDiscovery 案例中 SharePoint 來源的數目 |
100 |
界限 |
可新增至 eDiscovery 案例的 SharePoint 來源數目上限為 100。 |
| 每個 eDiscovery 案例中 Exchange 來源 (信箱) 的數目 |
1,500 |
界限 |
每個 eDiscovery 案例中 Exchange 來源 (信箱) 的最大數目為 1,500。 |
| eDiscovery 查詢的大小上限 |
16,000 個字元或 500 個關鍵字 |
界限 |
eDiscovery 查詢的大小限制為 500 個關鍵字或 16,000 個字元，端視先符合哪個條件。 |