設計大型清單並使清單獲得最大效能 (SharePoint Server 2010)

 

適用版本： SharePoint Server 2010

上次修改主題的時間： 2016-11-30

本文提供大型文件庫及大型清單效能的相關資訊。文中的建議是以 Microsoft SharePoint Server 2010 來進行一系列效能測試的結果。本文著重在大型清單的效能特性，以及不同設定對於大型清單及伺服器陣列效能的影響。SharePoint Server 2010 有幾項新的改良功能，讓建立及使用大型清單更加容易。不過， 建立及實作大型清單時，仍需謹慎規劃。您必須考量到許多因素，例如資訊結構、效能、損毀修復及管理。本文包含用來實作大型清單的資訊結構和功能，並包含特定設定對效能的影響。

另外，您也必須做一些會影響大型清單效能的關鍵設計選擇，包括權限、加入清單的欄數、檢視中的查閱欄數，以及用來組織清單的資料夾和索引。這些決策會影響清單的效能，而隨著清單的大小增加，此影響會變得更大。本文說明不同的設計選擇對大型清單效能的影響，讓您可以適當地設計符合效能需求的大型清單，還能符合商業需求，並提供良好的使用者經驗。

雖然本文的對象是 SharePoint Server 2010，但節流及限制也適用於 Microsoft SharePoint Foundation。本文所提及的各項功能，皆可大幅提升大型清單的使用經驗，而且只有 SharePoint Server 2010 才有這些功能。本文將不會區分 SharePoint Foundation 和 SharePoint Server。

本文內容：

• 了解查詢方法

• 大型清單案例範例

• 大型清單及 SharePoint Server 2010

• 效能測量及測試方法

• 節流及限制

• 其他限制

• 大型清單與一般清單的差異

• 大型清單設計及實作

• 總結

了解查詢方法

有三種主要方法可以用於存取清單資料，分別是清單檢視搭配中繼資料導覽、內容查詢網頁組件及搜尋。每種方法各有優缺點及適用的方法。

清單檢視及中繼資料導覽

清單檢視一律會存取 Microsoft SQL Server 資料庫。相較於其他方法，此方法的查詢效能較慢， 且需要比較多的 SQL Server 資源。清單檢視因為會轉譯大部分的 HTML，因此載入頁面的時間也比其他方法慢。對使用者而言，清單檢視在設定檢視、動態篩選資料，以及對文件執行動作 (例如管理版本和編輯屬性) 方面的效果最好。您可以使用中繼資料導覽篩選清單檢視結果。如果您需要有豐富的欄資料，並需存取清單項目動作，就應該使用清單檢視。如需大量讀取與查詢，則應考慮使用其他查詢方法。

內容查詢網頁組件

內容查詢網頁組件可以顯示以靜態方式設定，由入口網站地圖提供者為增進效能而快取之資料的檢視。內容查詢網頁組件會在轉譯基本的 HTML 之後被快取，藉此加快頁面載入的時間，讓相同的頁面可以容納多項查詢。內容查詢網頁組件應用於顯示相關清單項目、文件或頁面的連結。您雖可設定不要快取內容查詢網頁組件，但應侷限在輸送量需求低，或是未使用快取的頁面上 (例如查詢會隨存取之使用者而變更的頁面)。

搜尋

對於已經最佳化尋找內容 (相對於編輯屬性和即時查看更新) 效能的系統，可以使用搜尋網頁組件減輕其查詢負載。搜尋網頁組件可以設定成使用靜態查詢或使用者指定的查詢。搜尋網頁組件的效能雖好，但資料仍只會保持在最近一次編目的更新程度。亦即，其結果會比清單檢視和內容查詢網頁組件的結果舊。

大型清單案例範例

有幾種常見的大型清單案例需要您視情況做出不同的設計決定。例如，在共同作業大型清單案例中，使用者常需要新增內容和更新屬性。這種情況下的內容因為時有變更及更新，因此您應該不會想讓清單大小成長到數百萬個項目，以避免造成內容難以篩選。如果您是使用非結構化文件庫，本文將告訴您如何利用節流及限制來維護 SQL Server 的效能。下表是大型清單案例的考量項目。

案例	清單大小	管理	讀取率/更新率/新增率	新內容	使用者
非結構化文件庫	數百個	無管理員	讀取率高，新增率及更新率相當	手動上傳	數十個
共同作業大型清單或文件庫	數千個	非正式主題擁有者	高讀取率，更新率高於新增率	手動上傳	數百個
結構化大型存放庫	數萬個	專任內容監管員	讀取率極高，新增率居次，更新率極低	提交及上傳	數萬個
大型封存	數百萬	內容監管員小組	低讀取率與更新率，新增率高	提交	數萬個

非結構化文件庫

非結構化文件庫常用於小組或工作群組，所含的文件量一般從數十份到數百份不等。若不事先規劃這些文件庫，其規模可能會成長到大於清單檢視臨界值，進而影響新增欄之類的作業。潛在問題之一就是當檢視成長到大於 5,000 個項目時，使用者可能會發生清單檢視臨界值例外狀況。您可以藉由監視接近清單檢視臨界值的文件庫來減少此狀況 (文件庫的文件庫設定頁面上會顯示量表，指出文件庫正在趨近清單檢視臨界值)。

此案例通常有數十位到數百位不等的使用者，但很少會出現並行使用者，因此單一文件庫的負載很少會是問題。不過，這類文件庫可能很多。與其將文件庫規劃成支援特定的用途，不如著重文件庫規模的支援。

共同作業大型清單或文件庫

共同作業大型清單所含的項目數量從數百到數千，會用為大量作用中內容的存放區。共同作業大型清單通常包含知識管理解決方案、工程庫，以及銷售和行銷關聯存放庫。使用者主動新增和編輯內容 (大量讀取作業和寫入作業)。您可以設定文件庫的結構及管理方式，以保持文件庫的條理。不過， 因為使用者執行大量工作，所以可能會發生超出管理員控制範圍的事件。這樣很容易就會讓清單的成長速度超出預期，或是超過所規劃的限制。這種存放庫可能有數百位或數千位使用者，而其中又可能有數十位乃至於數百位的並行使用者。

與結構化存放庫或封存相較，共同作業大型清單更可能會出現系統管理變更狀況，例如新增和刪除資料夾、新增內容類型和欄，或是重組內容。因為清單大小的關係，可以利用清單檢視臨界值來防止這些動作。

結構化大型存放庫

結構化大型存放庫所含的項目數量從數千到數十萬，通常是已經完稿的內容，以及使用者或系統程序 (例如工作流程) 所提交的內容。結構化大型存放庫常會用於存放部門記錄封存、高價值的文件，以及顯示在網頁上的完稿文件。這類內容通常已經過結構化及良好的處理，因此比較容易控制清單的成長。此案例可能會有數十位或數百位的並行使用者，以及數以千計的使用者。雖然其讀取率遠大於寫入率，但仍有可能會更新內容，而且可能需會經常新增及刪除內容。部門或組織的知識管理存放庫就是結構化大型存放庫的範例之一。

在此案例中，徹底了解使用者需求，以及在解決方案正式啟用前執行全方位的測試，是很重要的。因此，解決方案在載入大量內容之前，已相當完整且確定。例如，可能需要設定適當的中繼資料導覽階層及篩選，以提供適當的內容瀏覽經驗。

大型封存

大型封存的範圍是從數千個到數百萬個的項目，可以在單一清單中，也可以分佈在多重清單中，最高階的是分佈在多重網站集合。此案例的讀取和更新量通常很低，一般只是用作長期儲存區，儲存為了符合標準或其他原因而必須保留的文件 (例如，為了配合法律需求，而必須保留七年的文件)。在此案例中，高輸送量的文件提交和刪除很重要。搜尋是擷取內容的主要方法。

大型清單及 SharePoint Server 2010

有助於 Office SharePoint Server 2007 大型清單的功能仍有助於 SharePoint Server 2010，而且其中有許多功能經過改良，可以大規模提供更好的效能。SharePoint Server 2010 也有許多新功能，有助於改善大型清單的效能，並且可以讓使用者有效地使用大型清單。本節摘要了 SharePoint Server 2010 中最新及改善的功能。

改善的功能

以下各節將討論 Microsoft Office SharePoint Server 2007 中在 SharePoint Server 2010 改善的功能。

內容查詢網頁組件

您可以設定內容查詢網頁組件，以顯示清單、內容類型及欄的篩選後結果。您可以排序結果，並選取要顯示的欄。這麼做可以讓內容查詢網頁組件適合在網頁上顯示大型清單內容。內容查詢網頁組件通常是快取而來。這樣可以加速頁面載入，並減少資料庫負載。在知識管理案例中，內容查詢網頁組件的用法之一，就是將其用在發佈頁面上，以顯示與網頁內容相關的文件連結。

SharePoint Server 2010 在下列主要案例中提供改善效能：

• 最佳化單一清單查詢，以更有效地利用索引

• 改善失效和重新整理演算法以及預設值，以改善使用者在執行寫入作業時的快取運用。

搜尋

SharePoint Server 2010 帶來新的搜尋功能，包括搜尋字詞精簡搜尋面板，以及改良的擴充性，可支援含 1 億個文件的次秒查詢延遲。另外還有 Microsoft FAST Search Server 2010 for SharePoint，可用來達到比 SharePoint Server 2010 搜尋更大的擴充點。

有助於在大型清單中尋找內容的一些新搜尋改善功能，包括在任意文字查詢中支援布林運算子；改善的運算子支援，例如等於、小於和大於；範圍精簡；以及關鍵字和屬性的前置詞比對。例如，查詢 “share*” 會找到包含 “SharePoint” 的結果。搜尋也有查詢建議，會依據使用者輸入的查詢內容來提供建議。搜尋使用者介面也改善了用於相關搜尋、首選、相關人員及關鍵字精簡的面板。

SharePoint Server 2010 搜尋也改善了擴充的相關功能。SharePoint Server 2010 搜尋支援索引、編目及查詢伺服器的擴充。其他改善包括更新的索引、更佳的恢復功能及更高的可用性。FAST Search Server 2010 for SharePoint 包含所有 SharePoint Server 2010 搜尋功能，並擴充極端要求、實體擷取、可調整的相關排名、視覺化首選、縮圖及預覽的範圍。

文件中心及記錄中心網站範本

文件中心及記錄中心是 SharePoint Server 2010 網站範本，可使來建立結構化存放庫。文件中心網站範本包含的功能例如預先設定的內容查詢網頁組件，以傳回登入使用者的相關結果；以及設有中繼資料導覽的文件庫。

記錄中心網站範本與文件中心網站範本相似，但它啟用了內容組合管理功能，可設定文件路由，並且有記錄文件庫，新增至其中的項目會自動宣告為記錄，而無法刪除。記錄中心網站範本是唯一沒有啟用文件剖析器的現成網站範本，可維護提交內容的精確度。停用文件剖析器會影響某些作業的效能，因此會比其他網站範本更適合用於大型文件儲存區 (數千萬個項目)。

新功能

本節說明 SharePoint Server 2010 中，有助於管理大型清單及清單效能的新功能。

內容組合管理

內容組合管理可用在任何網站上，以將內容路由設定至特定文件庫、資料夾，甚至其他網站。內容組合管理可用來依據中繼資料屬性，自動建立內容的資料夾。使用者可以從其他網站提交內容至內容組合管理，而不需擔心它要存放在檔案計劃中的哪裡。內容組合管理可用來將內容平衡至不同的資料夾中，以自動維護每個資料夾的大小上限。當達到指定的大小上限時，就會建立新的子資料夾來包含額外的項目。

中繼資料導覽

中繼資料導覽是新的 SharePoint Server 2010 功能，可讓使用者動態篩選清單，以尋找所需的項目。中繼資料導覽可讓使用者選取篩選選項，而且它用來執行查詢的方法是最有效率的。中繼資料導覽包含兩個部分。一部分是一組導覽控制項，可讓使用者篩選具有導覽階層及索引鍵篩選的清單。第二部分是重新排列及重試查詢的機制。

中繼資料導覽有重試和遞補邏輯，會利用索引有效率地嘗試執行查詢。如果查詢會傳回太多結果，查詢就會遞補，只傳回一部分結果，以獲得更好的效能。如果無法進行適當的查詢，就會發生遞補的情形，並針對一組有限的結果執行篩選。中繼資料導覽會自動建立索引。重試、遞補及索引管理的結合，讓中繼資料導覽成為有效使用大型清單非常重要的部分。篩選機制有兩種：導覽階層及索引鍵篩選。

導覽階層會使用樹狀控制項來導覽資料夾、內容類型、選擇欄位或受管理中繼資料字詞組的階層。這樣可以讓使用者使用樹狀控制項來對中繼資料階層進行樞紐分析，例如他們導覽資料夾的方式。當使用者在受管理中繼資料欄的階層中選取項目時，符合指定字詞或其任何子項子字詞的所有項目都會顯示。這就叫做包含子項 (descendant inclusion)，可用在連結至受管理中繼資料字詞組的欄位上。使用者可以再選取一次該項目，只針對該特定字詞進行篩選，而不包含子項子字詞。所有中繼資料導覽查詢都會遞迴，並顯示清單中所有資料夾的結果。

您可以設定索引鍵篩選來執行階層中結果的額外篩選。例如，您可以新增 [修改者] 欄作為索引鍵篩選，然後輸入使用者名稱，以取得 [修改者] 符合所輸入之使用者的結果。如需詳細資訊，請參閱中繼資料導覽及篩選 (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=219154&clcid=0x404) (可能為英文網頁)。下圖顯示中繼資料導覽階層及索引鍵篩選的範例。

受管理的中繼資料

受管理的中繼資料是一組新功能，新增更多資訊結構功能至 SharePoint Server。受管理的中繼資料功能包含稱為受管理中繼資料服務的共用服務。受管理的中繼資料服務可用來儲存能夠在整個 SharePoint Server 2010 部署中重複使用的字詞組。部分受管理中繼資料功能包括：

• 支援平面或縱深階層的字詞組

• 使用字詞組作為可用屬性的受管理中繼資料欄類型

• 可開啟供任何人新增字詞的字詞組，或是受限的字詞組，只有特定使用者可以管理字詞組

使用受管理的中繼資料欄及字詞組來組織內容，可讓您利用內容查詢網頁組件和中繼資料導覽之類的功能來協助使用者尋找及探索內容。受管理的中繼資料也有助於一般搜尋查詢，因為它會加入可用來分類文件的關鍵字。受管理的中繼資料可用在搜尋精簡面板中。下圖顯示受管理中繼資料導覽的範例。

節流及限制

SharePoint Server 2010 引進數項可設定的限制，有助於維護伺服器陣列效能。在 Web 應用程式層級，現在有可設定的節流及限制。加入這些節流及限制之後，個別使用者或程序的作業就不會對伺服器陣列效能產生不良影響。例如，清單檢視臨界值這個限制，可防止會影響超出特定清單項目數量的查詢。

複合索引

索引對大型清單而言很重要。在 SharePoint Server 2010 中，您現在可以建立複合索引。經常在兩欄上執行查詢時，複合索引會很有用，因為只在一欄上查詢的選擇性可能不夠。檢視不使用複合索引。不過，中繼資料導覽會使用複合索引。發生節流的狀況時，中繼資料導覽邏輯可以再試一次，並針對所選擇的篩選條件，使用可套用的複合索引及單一索引，以尋找符合查詢的完整或部分結果。

開發人員儀表板

開發人員儀表板會顯示每次載入頁面的詳細診斷資訊。儀表板預設為關閉。不過， 您可以手動將它開啟，或是將儀表板設定為隨時保持開啟狀態。當開發人員儀表板開啟時，您可以用它來取得資料庫查詢、載入時間或錯誤的相關資訊。開發人員儀表板可方便快速分析和診斷效能問題。下圖顯示開發人員儀表板。如果有大型清單和節流條件，就會在開發人員儀表板中看到中繼資料導覽功能，其中用於重試和部分結果的索引清單會出現在左邊的作業樹狀目錄中，而所嘗試的相異索引化 SQL Server 查詢會出現在右邊的清單中。

開發人員儀表板對於自訂網頁組件及查詢的偵錯也很有用。如需如何啟用開發人員儀表板的詳細資訊，請參閱部落格：使用物件模型/Powershell 來啟用開發人員儀表板 (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=219613&clcid=0x404) (可能為英文網頁)。

內容迭代器

內容迭代器開發人員 API 簡化了對大型清單編寫程式碼的作業，這在有新的清單檢視臨界值限制時特別重要。內容迭代器是擷取內容的一種方法，可以在上面分小組執行作業，而不需要對整個資料集執行作業。這樣可以防止作業超過清單檢視臨界值。

遠端 BLOB 儲存

根據預設，SharePoint Server 2010 會將檔案 (二進位大型物件 (BLOB) 資料儲存在 SQL Server 資料庫中。內容資料庫中的大部分都是 BLOB 資料。遠端 BLOB 儲存 (RBS) 可讓此資料儲存在 SQL Server 外面，這樣可能會有比較便宜的儲存選項，並可減少內容資料庫大小。遠端 BLOB 儲存是文件庫 API 集，納入作為 SQL Server 2008 的附加元件功能套件。協力廠商遠端 BLOB儲存提供者必須使用遠端 BLOB 儲存 API。

效能測量及測試方法

本節說明先前用於本文討論之測試的測試方法。與此方法相異之處會在資料出現的地方註明。

硬體及伺服器陣列設定

測試伺服器陣列設定指定在下列圖表和表格中。測試設定有兩個層面與現實中的大部分部署大不相同。特別是：

• 以前會使用 NTLM 驗證來避免讓網域控制站變成瓶頸。這樣可以稍微改善效能。

• 應用程式伺服器包含用來記錄資料庫的 SQL Server 執行個體。這麼做是為了減少主要 SQL Server 執行個體上的負載，因為記錄層級比現實中的部署高太多了。

電腦名稱	兩部網頁伺服器	一部應用程式伺服器	一部資料庫伺服器
角色	前端網頁伺服器	應用程式伺服器	SQL Server 執行個體
處理器	2px4c@2.33 GHz	2px4c@2.33 GHz	4px2c@3.19 GHz
RAM	8 GB	8 GB	32 GB
作業系統	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64
存放區及其幾何 (包括 SQL Server 磁碟設定)	50 + 18 + 205 GB	50 + 18 + 300 GB	磁碟陣列 – 15 個 450 GB @ 15 K RPM 的磁碟
NIC 的數目	2	2	2
NIC 速度	1 Gigabit	1 Gigabit	1 Gigabit
驗證	NTLM	NTLM	NTLM
軟體版本	SharePoint Server 2010 (測試版)	SharePoint Server 2010 (測試版)， SQL Server 2008 CTP 3	SQL Server 2008 CTP 3
SQL Server 執行個體數	無	1	1
負載平衡器類型	硬體	無	無
輸出快取設定
物件快取設定
BLOB 快取設定
ULS 記錄層級	中	中	中
使用狀況資料庫位置		X
使用狀況資料庫設定 (正在記錄的內容)
IRM 設定	無	無	無
防毒設定	無	無	無

資料庫類型	資料庫數目	RAID 設定
暫存資料庫	1	0
設定資料庫	1	0
內容資料庫 #1	1	0
設定檔資料庫	1	0
搜尋資料庫	1	0
分類資料庫	1	0

測試負載

測試是在最佳載入點 (或綠色區域) 以一般混合作業來進行。為測量特定變更，測試是在變數改變的每個點進行。為尋找最佳載入點，加入了額外的執行緒來滲透環境，並維持在下列測量值之下：

• 第 75 個百分位數延遲少於 1 秒

• 前端網頁伺服器 CPU 少於 50%

• SQL Server CPU 少於 50%

• 應用程式伺服器 CPU 少於 50%

• 失敗率小於 0.01%

測試定義

下表定義測試，並提供用於各測試的程序概觀。

測試名稱	測試描述
文件上傳	上傳文件。 編輯和更新文件的屬性。
文件上傳及路由設定	上傳文件。 編輯和更新文件的屬性。 路由設定符合路由規則的文件。
文件下載	下載文件。
存取文件庫	存取文件庫清單檢視頁面。
以內容查詢網頁組件存取首頁	存取含有三個內容查詢網頁組件的文件中心網站首頁。 快取的內容查詢網頁組件傳回 15 個評分最高的文件。 快取的內容查詢網頁組件傳回 15 個最新的文件。 非快取的內容查詢網頁組件傳回目前使用者最新修改過的 15 個項目。
受管理的中繼資料遞補查詢	傳回超過 5,000 筆結果的清單檢視查詢，在單值受管理中繼資料欄進行篩選。
受管理的中繼資料選擇性查詢	傳回 1,000 筆結果的清單檢視查詢，在單值受管理中繼資料欄進行篩選。
內容類型遞補查詢	傳回超過 5,000 筆結果的清單檢視查詢，依內容類型篩選。
內容類型選擇性查詢	傳回 1,000 筆結果的清單檢視查詢，依內容類型篩選。

測試混合

每個測試混合的架構各不相同。測試是使用 Visual Studio 測試系統來進行的。先填入每個測試的特定資料點，然後執行測試混合，進行 2 分鐘的準備，以及 10 分鐘的資料收集。本文顯示的結果為該 10 分鐘的平均值。下表顯示單一測試混合中每個解決方案的百分比。

解決方案名稱	混合中的百分比
文件上傳 (包括編輯文件屬性)	20
文件下載	20
存取文件庫	20
以內容查詢網頁組件存取首頁	10
受管理的中繼資料遞補查詢 (超過 5,000 筆結果)	5
受管理的中繼資料選擇性查詢 (100 筆結果)	10
內容類型遞補查詢 (超過 5,000 筆結果)	5
內容類型選擇性查詢 (100 筆結果)	10

節流及限制

限制可防止會對伺服器陣列效能造成不良影響的作業。這些預設值經過測試及謹慎的選擇。針對某些限制，例如清單檢視臨界值，強烈建議您不要變更該值。請謹慎考量變更這些限制的影響。如果這些限制會阻礙作業執行，請先考慮變更作業，以較有效率的方式來執行，而不要變更限制來納入執行效能不佳的作業。本節中包含的大部分節流及限制都可以在管理中心設定，請前往 [管理 Web 應用程式]，然後從特定 Web 應用程式的功能區選取 [一般設定 – 資源節流]。

清單檢視臨界值

SharePoint Server 2010 支援含有數千萬個項目的文件庫及清單。您可以使用資料夾、標準檢視、網站階層及中繼資料導覽，以建立龐大的文件庫。若要使用清單檢視或 Collaborative Application Markup Language (CAML) 查詢從大型清單擷取資料，則必須使用資料夾及/或索引來分割資料。否則，搜尋是可以有效率存取資料的唯一機制。單一文件庫可支援的項目數會因為文件和資料夾的組織方式、儲存文件的大小和種類、文件庫的使用情況以及文件庫中的欄數，而有所不同。

根據預設，清單檢視臨界值會防止牽涉到超過 5,000 個項目的作業，例如會傳回超過 5,000 個項目的查詢，或是新增一欄至含有超過 5,000 個項目的清單。雖然這是可供設定的預設值，但強烈建議您維持此設定。如果在含有超過 5,000 個項目的清單上執行查詢的效能不佳，當您增加此限制時，整體輸送量會大幅降低。

有些作業 (例如非索引查詢或新增欄至清單) 所花費的時間和資源與清單中的項目數成正比。在小型清單中，這樣沒關係，因為項目很少，所以作業很快。隨著清單大小增加，這些作業所花費的時間就愈長，所使用的資源就愈多。清單檢視臨界值會加以封鎖，而不會讓這些作業無限制地執行。您可以將清單檢視臨界值想成高速公路沿邊的護欄，讓您知道您應該變更查詢，以及如何存取資料，或是您應該在伺服器陣列用量低時執行作業。

清單檢視臨界值是資料庫作業 (例如查詢) 一次可以包含的清單或文件庫項目數上限。此值預設為 5,000 個項目。此限制對大型清單有很大的效用，因為依據此臨界值的定義，大型清單是所擁有的項目數超過此限制的清單。超過此限制的作業會受到節流。像是在超過此限制的清單上建立索引之類的作業會受到阻礙，因為該作業會影響超過 5,000 個項目。此限制會阻止已選取 (可使用篩選準則有效篩選的項目 ) 超過 5,000 個項目的查詢。此限制也會阻止在未編製索引的欄上進行篩選的查詢。這是因為在未編製索引的欄上進行篩選 (有時會排序) 的查詢，必須對清單中的所有項目執行篩選，以擷取正確的資料集，而且它其操作的項目超過清單檢視臨界值。此限制的預設值是依據伺服器陣列和清單效能，以及 SQL Server 管理鎖定的方式。建議您不要變更此限制。

為儘量減少資料庫競用，SQL Server 使用低層級鎖定作為策略，以確保更新精確，而不會對存取其他列的使用者造成不良影響。不過，如果讀取或寫入資料庫作業 (例如查詢) 同時造成超過 5,000 列被鎖定，則讓 SQL Server 將鎖定擴大到整個表格，直到資料庫作業完成，會比較有效率。當此鎖定擴大發生時，會阻止其他使用者存取表格。如需鎖定的詳細資訊，請參閱鎖定擴大 (資料庫引擎) (https://go.microsoft.com/fwlink/?linkid=219156&clcid=0x404)。

下圖顯示當清單檢視臨界值調整時，對大型清單進行混合查詢的輸送量。此混合查詢包含會傳回清單中所有項目的查詢，所以當清單檢視臨界值提高，就會傳回更多項目。甚至將限制從預設的 5,000 變更為 10,000，對效能也有很大的影響。與其提高或降低清單檢視臨界值來改善效能，建議您還是不要變更預設清單檢視臨界值，而是要確定查詢執行良好。

因為作業執行不佳，所以發生清單檢視臨界值例外狀況。作業應重新設定。您不應提高限制，而是要思考為什麼執行的作業沒有效率，然後加以修正。在更糟的情況下，您可以針對特定清單，將 EnableThrottling 設定暫時變更為 false，以忽略清單檢視臨界值。此動作只能在清單層級執行，而不能對網站執行。這麼做僅限允許清單存取，直到可以進行變更，以修正被清單檢視臨界值封鎖的低執行效能作業。EnableThrottling 設定應儘快變更回 true。

伺服器陣列管理員和前端網頁伺服器 (查詢來源) 本機電腦管理員不會被清單檢視臨界值封鎖。這些使用者應細心瀏覽設定不正確的大型清單，而且在執行測試時，也必須謹慎小心。事情看起來可能會如預期般運作，但是傳回給使用者的資料大不相同。如需清單檢視臨界值會阻止的作業清單，請參閱本文稍後的＜清單檢視臨界值封鎖的作業＞。

同樣地，計時器服務也可以用不受清單檢視臨界值保護的帳戶來執行。雖然這會讓某些狀況 (例如在大型清單上延期建立索引) 可行，但是您通常要特別小心確認您的程式碼會避免執行大型清單作業。

清單檢視臨界值

預設值：5,000	存在於 2007 中：否	可設定：是
設定位置：管理中心，依 Web 應用程式

稽核者及管理員的清單檢視臨界值

預設值：20,000	存在於 2007 中：否	可設定：是
設定位置：管理中心，依 Web 應用程式

稽核者和管理員的清單檢視臨界值，是用於特定服務帳戶 (例如搜尋查詢帳戶，或物件快取進階讀取者及進階寫入者帳戶) 的清單檢視臨界值。例如，內容查詢網頁組件會自動使用此限制來快取大型查詢的結果，因而節省伺服器資源。如果是依據 Web 應用程式安全性原則，以進階讀取者或進階寫入者帳戶來執行，您就可以使用自訂程式碼來要求使用這個較高的限制。

允許物件模型覆寫

預設值：是	存在於 2007 中：否	可設定：是
設定位置：管理中心，依 Web 應用程式

允許物件模型覆寫會指定服務帳戶是否可以為稽核者和管理員使用清單檢視臨界值。伺服器陣列管理員必須啟用物件模型覆寫，並以程式設計方式指定清單為例外。然後，具有適當權限的程式設計師可以用程式設計方式，要求其查詢或清單為稽核者和管理員使用較高的清單檢視臨界值大小，以善加利用。將該值變更為「否」，稽核者或管理員執行的自訂程式碼 (即使有要求覆寫) 會受制於清單檢視臨界值，而不是依據稽核者和管理員的較高限制。建議您將此設定保留預設值，只為稽核者和管理員設定清單檢視臨界值 (需要的話)。

每日時間範圍

預設值：關閉	存在於 2007 中：否	可設定：是
設定位置：管理中心，依 Web 應用程式

您可以設定每日時間範圍，讓作業可以在不受制於清單檢視臨界值的情況下執行。時間可以用 15 分鐘增量調整，最多 24 小時。在每日時間範圍內開始的資料庫作業或查詢會繼續進行，直到完成，即使沒有在指定的時間範圍內完成也一樣。預設沒有設定每日時間範圍，因為各部署之間的離峰時間大不相同。因此，這就留給管理員決定。建議您，除非是在很少人使用 Web 應用程式的適當下班時間範圍內，否則不要指定每日時間範圍。這樣可以讓使用者在伺服器陣列用量低很多的時間範圍內，執行大型清單的管理作業，例如建立索引。

唯一權限

當清單中的唯一權限數增加，效能也會隨之降低。您應該重新考量大型清單中所有或大部分內容必須以唯一權限保護的任何設計。唯一權限數介於 0 到 1,000 之清單上的作業輸送量差異大約為 20%。每個清單有 50,000 個唯一權限的可設定預設值。不過，建議您考慮將此限制降低至 5,000 個唯一權限，針對大型清單，請考慮使用唯一權限數儘可能最少的設計。這樣不但有助於效能，對管理能力也有幫助。

建議您下列事項：

• 儘可能減少個別項目的唯一權限用量，並簡化大部分項目都需要有唯一權限的清單設計。

• 如果需要唯一權限，請嘗試只在清單或資料夾層級設定，並儘可能減少需要唯一權限的個別項目。

• 如果每個項目都需要個別權限，請重新考量您的設計。研究如何在多個清單之間分配項目，或是將項目組織成資料夾和群組，以授與適當的存取權，而不要將唯一權限賦予每個項目。

設定微調權限會影響效能，而且如果很多個別項目上的設定都不一樣，也很難管理。在超過清單檢視臨界值的清單或資料夾上設定微調權限將會被封鎖，因為有太多個別項目必須更新。不過， 設定微調權限也會影響其他方面的效能。因此，每個清單預設有 50,000 個唯一權限的可設定限制。如果您嘗試在達到此限制之後宣告唯一權限，系統就會阻擋您這麼做。與清單檢視臨界值不同的是，此限制套用於您在項目上建立唯一權限時，而不是套用在查詢時。

每當某項目 (例如資料夾) 的權限繼承中斷，就會將其視為此限制的唯一權限。每當權限繼承中斷，就會建立新的範圍識別碼。每當您在檢視上查詢，就會加入範圍表格。然後，當執行查詢時，就必須剖析及處理每個唯一存取控制清單 (ACL)。清單中的大量唯一權限會對效能造成不良影響，建議您不要這麼做。當清單中的唯一權限數成長，查詢效能也會隨之降低。即使預設限制為 50,000 個唯一權限，您也應考慮將此限制降低至 5,000 個唯一權限。

唯一權限

預設值：50,000	存在於 2007 中：否	可設定：是
設定位置：管理中心，依 Web 應用程式

列換行

新增欄至清單時，這些欄會對應至 SQL Server 資料庫資料表中的欄。資料庫資料表中的每一列都支援固定數量的各種不同欄類型。例如，單一資料庫資料表列支援 8 個日期和時間欄，以及 12 個數字欄。如果有超過 8 個日期和時間欄，每個清單項目就會使用 2 個資料庫資料表列。

若為小型清單，則可忽略此列換行的效能影響。不過，若為大型清單，影響就很大了。您最多可以到發生列換行之前的任何欄數限制，但只有一個欄類型必須超過限制，讓列換行發生。

下表顯示在發生列換行之前，特定資料類型的欄數。

欄類型	每個表格列的欄數
單行文字 或 選擇及多行文字	64 32
日期和時間	8
是或否	16
數字和貨幣	12
計算	8
整數、單值查閱、人員與群組、受管理的中繼資料	16
唯一識別碼	1

就大部分作業而言，列換行會導致輸送量降低，每多一列大概會降低 35%。若要查看清單使用多少列，您必須分析清單結構描述，並檢查清單欄位的欄類型。

下圖顯示當用於清單的 SQL Server 資料庫列數增加，以容納更多受管理的中繼資料欄時，唯讀查詢的效能。為了到第二列，新增了 15 個受管理的中繼資料欄至清單，為了到第三列，新增了 31 個受管理的中繼資料欄至清單。測試的進行方式是僅使用在清單項目上篩選的查詢。每多一列，輸送量就降低 35%。

列大小限制

預設值：6	存在於 2007 中：否	可設定：是
設定位置：僅限物件模型，SPWebApplication.MaxListItemRowStorage

列大小限制指定用於清單中每個項目之資料庫內部的表格列數上限。為容納含有許多欄的寬幅清單，每個項目會在數個內部表格列上換行，最多 6 列。例如，如果您的清單中有許多小欄，是個包含數百個 [是/否] 欄的清單，就可能達到此限制。在此情況下，您無法新增更多 [是/否] 欄至清單。不過，您也許可以新增其他類型的欄。因為每多一列都會增加負荷，所以如果是大型清單，您應儘量減少相同類型的欄數，以避免列換行。

查閱欄及清單檢視

清單檢視中的每個查閱欄都會導致與另一個表格連接。檢視中每多一個查閱欄，就會增加中繼資料導覽及清單檢視查詢的複雜度。除了標準查閱欄之外，單值受管理的中繼資料、多值受管理的中繼資料、單值人員與群組欄以及多值人員與群組欄也都算是查閱欄。新增查閱欄至檢視並不會造成效能逐漸或直線降低，效能反而有點穩定，直到 8 欄之後才會急速降低。

下圖顯示隨著檢視中的查閱欄數增加，輸送量所產生的變化。如您所見，從 0 到 8 的效能變化相當穩定，但是在 10 個查閱欄時，輸送量大量減少。此測試只使用一列的清單來執行。如果清單有列換行，效能會降得更快。

下圖顯示隨著檢視中的查閱欄數增加，SQL Server CPU 使用量所產生的變化。如您所見，在 10 個查閱欄時變化非常大。針對具有大量查詢的清單，如果檢視包含 8 個查閱欄，會導致查詢使用不成比例的大量 SQL Server 資源。建議您不要將此限制變更為大於 8。

雖然這樣的效能降低不是針對清單上的查閱欄總數，只是針對檢視或查詢中的查閱欄數，但是 SharePoint Workspace 無法同步處理含有 8 個以上查閱欄的任何清單。無論這些欄是否用在檢視中都一樣。

清單檢視查閱臨界值

預設值：8	存在於 2007 中：否	可設定：是
設定位置：管理中心，依 Web 應用程式

其他限制

本節說明本文其他部分沒有談到的限制。

每個清單的索引

預設值：20

存在於 2007 中：是，限制為 10

可設定：否

前述表格顯示每個清單可建立的索引限制，包括複合索引以及 SharePoint Server 2010 建立的索引。此限制不可設定。

資料工作表檢視及匯出至 Excel

預設值：50,000

存在於 2007 中：否

可設定：否

前述表格顯示可用於匯出至 Microsoft Excel 及資料工作表檢視的項目數上限。不過，資料工作表檢視會被清單檢視臨界值封鎖。因此，如果您的清單檢視臨界值為 5,000 個項目，而您的清單檢視中有 5,000 到 50,000 個項目，當您嘗試使用資料工作表檢視時，就會收到清單檢視例外狀況訊息，即使資料工作表檢視限制更高也一樣。

SharePoint Workspace

預設值：每個清單 30,000 個項目

存在於 2007 中：否

可設定：否

Microsoft SharePoint Workspace 有一個不可設定的限制會封鎖同步處理含有超過 30,000 個項目的清單。如果清單中包含 30,000 個項目，使用者就無法使用 SharePoint Workspace 來同步處理清單，而且無法選取項目來進行同步處理。

大型清單與一般清單的差異

當清單超過清單檢視臨界值時，會封鎖一些先前可能運作過的作業。最大的考量是預設清單檢視，因為這是使用者最常用來存取清單的方式。清單檢視必須設定為能夠讓大型清單正確運作。例如，如果清單根目錄包含的項目超過清單檢視臨界值，當您存取清單時，就會發生錯誤。如果有啟用中繼資料導覽功能，則會顯示部分結果，而不會顯示錯誤。

清單檢視臨界值會封鎖影響的項目數超過清單檢視臨界值的任何資料庫作業；臨界值不只會封鎖所傳回或修改的項目數。例如，如果您在傳回 100 筆結果的非索引欄上使用篩選，而清單中包含 10,000 個項目，則查詢失敗，因為它必須掃描所有的 10,000 個項目。如果您新增索引至該欄，則會限制作業為只有 100 個項目，這樣就會成功。

大型清單上的作業可分類成下列兩個群組：

• 清單超過清單檢視臨界值   當整個清單的大小超過清單檢視臨界值時，即使項目劃分成資料夾，有些作業還是會遭到阻止。這些作業包括遞迴查詢 (例如管理取出的版本)，無論項目所在的資料夾為何，都會在所有項目上運作。傳回所有不含資料夾之項目的檢視也會遭到阻止。此外，會影響整個清單的作業 (例如新增欄以及建立或刪除索引) 會被封鎖。

• 容器超過清單檢視臨界值   某些作業會因為資料夾或清單根目錄包含的項目超過清單檢視臨界值而遭到阻止。例如，如果清單包含 10,000 個項目，而資料夾包含 3,000 個項目，您可以將資料夾重新命名或刪除。不過，如果資料夾包含 6,000 個項目 (超過清單檢視臨界值)，則不能刪除資料夾，因為該作業超過清單檢視臨界值。

當清單超過清單檢視臨界值時，您必須計劃正確地設定檢視及其他導覽選項。您最好事先設定檢視及其他導覽選項，但是清單常會成長到超過清單檢視臨界值，而需要動作。有些作業 (例如建立欄，或是在含有許多項目的清單中將欄編製索引) 會花很長的時間。這些作業會被清單檢視臨界值阻止。不過，可以在每日時間範圍內或由伺服器陣列或電腦系統管理員執行。您應該先計劃這些作業，再加以執行。如果清單已經太大了，請計劃使用每日時間範圍或系統管理認證來執行這些作業。

清單會變得很大，以致於在使用網頁瀏覽器來執行某些作業時，可能會發生逾時的狀況。例如，如果清單包含數百萬個文件，可能會花太長的時間來新增欄。為完成此作業，您需要使用 Windows PowerShell，並確定您是在離峰期間執行，因為它會封鎖其他使用者的作業。

清單檢視臨界值封鎖的作業

下表列出清單檢視臨界值封鎖的作業。

當清單超過清單檢視臨界值時封鎖的作業

作業	描述
新增/移除/更新清單欄	所有欄 (包括查閱及計算結果欄)，以及許多種類的更新，例如類型變更或唯一性變更。有些更新 (例如名稱變更) 不會影響到清單中的每個項目，所以不會被封鎖。
新增/移除/更新清單內容類型	會影響清單中的每個項目，所以只要清單的項目數超過清單檢視臨界值，就會封鎖作業。
建立/移除索引	會影響清單中的每個項目，所以只要清單的項目數超過清單檢視臨界值，就會封鎖作業。
管理沒有存回版本的檔案	因為清單項目數超過清單檢視臨界值而失敗的非索引遞迴查詢。
非索引遞迴查詢	包括篩選及某些排序。當清單大小超過清單檢視臨界值時，此作業失敗。因為沒有索引，所以會對整個清單進行完整掃描，還會傳回所有項目，並忽略資料夾。
交叉清單查詢	包括依內容查詢網頁組件的查詢，並且會遵照稽核者及管理員的清單檢視臨界值設定，預設值為 20,000 個項目。如果作業包含超過 20,000 個項目，則查詢失敗。
強制執行關聯行為的查閱欄	當所參照的清單包含超過清單檢視臨界值的項目數時，您不能建立強制執行關聯行為的查閱欄。
刪除清單	會影響清單中的每個項目，所以只要清單的項目數超過清單檢視臨界值，就會封鎖作業。
刪除網站	如果網站中的所有項目總和大於清單檢視臨界值，則會防止刪除網站，因為會影響到太多項目。
將清單另存為含有資料的範本	會影響清單中的每個項目，所以只要清單的項目數超過清單檢視臨界值，就會封鎖作業。
顯示清單檢視中的總數	會對清單中的每個項目執行查詢，所以只要清單的項目數超過清單檢視臨界值，就會封鎖作業。
啟用/停用清單中的附件	會影響清單中的每個項目，所以只要清單的項目數超過清單檢視臨界值，就會封鎖作業。

當容器超過清單檢視臨界值時封鎖的作業

作業	描述
刪除/複製/重新命名資料夾	當資料夾包含的項目數超過清單檢視臨界值時，就會失敗，因為會影響到太多列。
在非索引欄上篩選的查詢	當容器 (資料夾或清單) 包含的項目數超過清單檢視臨界值時，就會失敗。作業會對整個資料夾進行完整掃描，因為沒有索引。
設定微調安全性權限	當您嘗試設定微調權限的清單或資料夾包含的項目數超過清單檢視臨界值時，就會失敗，因為會影響到太多列。雖然您不能在清單本身或是包含的項目數超過清單檢視臨界值的資料夾上設定權限，但還是可以在大型清單中的子項目 (例如文件) 上設定微調權限。
在檔案總管中開啟	如果容器包含的項目數超過清單檢視臨界值 (不包括子資料夾中的項目)，就不會顯示任何項目。如果資料夾有 8,000 個項目，但有一個子資料夾包含 4,000 個項目，而根目錄中只有 4,000 個項目，則在 [檔案總管中開啟] 有效。如果清單根目錄包含的項目數超過清單檢視臨界值，則 [在檔案總管中開啟] 不會顯示任何內容。若要使用 [在檔案總管中開啟]，清單必須在任何容器的根目錄中，將項目組織成數量低於清單檢視臨界值的資料夾。

效果不如預期的可用功能

本節包含因為大型清單，而使得效果不如預期之功能的相關資訊。

資料工作表檢視

如果清單成長超過清單檢視臨界值，就不會停用文件庫功能區索引標籤中的資料工作表檢視按鈕。不過，如果清單大小超過清單檢視臨界值，檢視就會載入一些項目，但會顯示訊息表示「您沒有檢視整份清單的權限，因為它大於管理員所強制的清單檢視臨界值」。您可以在清單的設定中，從功能區停用資料工作表檢視選項。因為還有 50,000 個項目的固定限制，所以即使清單檢視臨界值高於 50,000 個項目，此檢視還是會被封鎖。

規劃大型清單設計及實作

在實作大型清單之前，請考量商業案例及需求。像是服務等級協定 (SLA)、備份和還原的時間、內容大小、內容數量 (項目數) 及存取時間之類的需求，都是重要的考量點。依據應用程式的大小及需求量，您必須在多個層級做重要的抉擇，包括硬體、內容儲存區及 SharePoint Server 2010 資訊結構。雖然現有網站中的現有共用硬體及單一文件庫，就可以讓含有數十個並行使用者及數萬個文件的文件存放庫運行地很好，但是具有數百萬個項目及數百個並行使用者的大型應用程式，可能需要獨立的硬體專用於特定專案。

規劃的最後結果應該是包含下列項目的清單：欄類型 (名稱、資料類型和使用狀況)、索引、資料夾結構、導覽頁面和連結的使用狀況、規劃的權限結構、評估的項目數，以及資料大小總計。細節也應包含所要執行之查詢種類的相關資訊，以及如何存取、建立和更新清單中的資料。

規劃好大型清單的設計和實作之後，下一步就是要設計和建置原型。這個規劃階段有關設計大型清單、實作概念證明，以及驗證其有效。在此階段中，將大量內容填入測試環境，以驗證對資料存取及效能的假設會很有用。設計程序的最後結果應該是下列各項的概念證明：預定清單；欄、內容類型、資料夾結構、檢視、索引的文件；用於中繼資料導覽或其他擷取方法的欄；所使用的任何分類；各種網頁組件的使用狀況；以及任何其他功能 (例如內容組合管理) 的使用狀況。

評估內容大小

針對大型清單，評估各種數量來規劃容量和決定設計是很重要的。有幾個重要數量是您應該要規劃的，如下所示：

• 內容資料庫大小總計

• 檔案大小平均及上限

• 版本數

• 內容數量 – 清單中的項目總數

內容資料庫大小

在規劃所需的磁碟空間和硬體時，以及在推測可為備份、還原和服務等級協定支援的項目時，內容資料庫大小總計是很重要的。在推測備份及還原所需的停機時間量時，整體內容資料庫大小是最重要的。

若要預估內容資料庫大小，可以計算平均文件大小乘以每個文件的平均版本數，再乘以預期的文件數。除了檔案之外，要再為內容資料庫資料加上 20%。這個數字最高，因為版本大小通常會隨著時間增加，所以存回文件的平均檔案大小數通常會高於所有版本的平均檔案大小數。您應加入大量緩衝區，以防清單成長大於預期，除非您有可以控制內容量的有效機制。

檔案大小平均及上限

必須要有檔案大小上限，才能確保為可上傳的檔案指定正確的 Web 應用程式設定 (預設值為 50 MB，最大可達 2 GB)。平均檔案大小可用來幫助了解內容可成長的速度，以及預估內容大小總計。若要預估平均檔案大小，可評估目前作為預定系統之系統中的檔案。

平均版本數

您必須考量版本設定，因為它會大量增加內容的大小。有一些方法可以用來限制版本。例如，您可以使用資訊管理保留原則，在特定時間量之後，刪除所有舊版本，或者您可以限制所要儲存的版本數。其他因素也會影響版本，例如，如果存放庫使用內容組合管理，將所有內容提交至存放庫，則可能會完全沒有版本，因為內容組合管理只會複製最新存回的版本。如果存放庫中的文件是由使用者主動編輯，您可能就必須考量共同撰寫；每個共同撰寫工作階段都會自動建立版本。考量存放庫的使用狀況，並評估現有的解決方案，以預估將會為文件建立的平均版本數。

內容數量

內容數量是單一清單中的項目總數。若要預估內容數量，您應評估內容的現有來源，以及要移至新系統的內容有哪些；或是調查有多少使用者會使用系統，以及系統的目的為何。有一些其他相關數字，包括每個容器的項目數，以及每個中繼資料樞紐分析或索引篩選的項目數。當您規劃檢視和中繼資料導覽時，這些數字也很重要。

遠端 BLOB 儲存

有大量儲存需求的清單，會觸發如何儲存文件的根本決定。根據預設，SharePoint Server 2010 會將所有文件當作 BLOB 儲存在 SQL Server 資料庫中。SharePoint Server 2010 及 SQL Server 2008 提供遠端 BLOB 儲存 API，可讓文件儲存在 SQL Server 資料庫外面，以降低資料庫大小。是否使用遠端 BLOB 儲存主要取決於節省成本考量。

Microsoft 目前的測試顯示，遠端 BLOB 儲存會使輸送量減少 5% 到 10%，若為大型檔案，則感覺不到延遲的差異。不過，依據所使用的特定遠端 BLOB 儲存提供者，效能會有所不同。藉由使用遠端 BLOB 儲存，內容資料庫大小會降低。不過，這不見得表示您可以在內容資料庫中儲存更多項目。效能會受 SQL Server 資料庫中的清單項目數量影響；雖然 BLOB 移除了，但清單大小並沒有變更。很少會有成本效益可輕易超越效能考量的狀況：

• 封存，非共同作業資料

• 儲存非常大型的 BLOB，例如不常更新的視訊及圖像

使用遠端 BLOB 儲存可以新增更多伺服器和技術至伺服器陣列，並且需要增加遠端 BLOB 儲存提供者。遠端 BLOB 儲存提供者可支援在 SQL Server 資料庫外部比較便宜的存放區中儲存 BLOB。SQL Server Enterprise 需要使用遠端 BLOB 儲存 API。

遠端 BLOB 儲存變成符合成本效益的跨越點可能是在資料的 TB 範圍內。除非您有 TB 大小的內容資料庫，才不需要使用遠端 BLOB 儲存。您必須謹慎考量備份和還原以及服務等級協定。遠端 BLOB 儲存讓損壞修復更加困難，因為它需要將兩項技術同步處理。主要的重點是損毀之後還原系統以及處理備份和復原 BLOB 所需的時間。如需詳細資訊，請參閱＜RBS 概觀 (SharePoint Server 2010)＞。

清單結構

選取適合大型清單專案的結構很重要，因為決策一旦實作之後，就很難再變更。所以請事先規劃並考量內容的大小和數量、存放庫的使用狀況、內容的新增和更新方式，以及內容的存取方式。這些都會影響到內容的組織方式 (在單一清單、多個清單，甚或多個網站集合中)、所使用的中繼資料為何，以及內容的擷取方式。這些決策對大型清單特別重要，因為在有大量內容的情況下，會變得更難重新設計系統的使用方式。

單一清單、多個清單或多個網站集合

當您設計大型清單解決方案時，務必考量單一清單結構是否適當。在決定將內容放在單一清單時，應視商業需求而定，例如在內容上工作及探索時，是否容易使用。在許多執行個體中，使用多個清單可能比較明智。以 SharePoint Server 2010 的功能和可用資源來建立具有絕佳可用性及使用者經驗的成功實作，應該是您的首要優先考量。

使用單一清單，讓使用者容易尋找及使用內容，他們就不必決定要將內容放在哪裡，或是必須存取哪個清單，才能找到所要尋找的項目。不過，隨著內容數量增加，尋找內容也會比較困難，尤其是使用篩選檢視或導覽資料夾之類的方法時。當清單開始達到數十萬個項目時，使用中繼資料導覽可能會變得困難。查詢可能會傳回數百或數千筆結果，因為不夠明確。

例如，如果索引的領域中有 5,000 個字詞，而每個字詞都有相等的符合篩選項目數量，則篩選一個字詞就會產生 20 筆結果含有 100,000 個項目的清單，200 筆結果含有 1,000,000 個項目的清單。如果清單大小太大，使用者選取的許多篩選就不會傳回合理的結果集供使用者尋找他們要尋找的項目。如果專案中有使用者通常能夠分辨的多種明確不同內容，則應考慮使用多個清單。

在非常大的擴充點上 (例如大型封存案例)，很值得考慮多網站集合結構。新的 SharePoint Server 2010 功能可讓網站集合分組在一起，以平衡負載文件。內容組合管理功能可用來將文件在多個網站集合之間進行路由設定。必須使用搜尋來擷取文件。這對長期儲存很好，因為這樣可以跨多個網站集合及範圍來平衡內容，以支援比單一清單更多的文件。

清單建議摘要

• 在下列情況下，為大量項目使用單一清單：

  • 將項目放在不同清單中不合邏輯時。

  • 可提供最佳使用者經驗時。

• 在下列情況下，為大量項目使用多個清單：

  • 將項目分組成多個清單符合邏輯時。

  • 可提供最佳使用者經驗時。

  • 使用者不會困惑要使用哪個清單來新增或尋找內容時。

• 在下列情況下，使用多網站集合結構：

  • 存放庫需要在單一存放庫中支援數千萬個以上的項目。

  • 將項目分組成多個網站集合符合邏輯時，例如，依年份分割資料。

中繼資料

使用 SharePoint Server 2010 時，中繼資料及內容類型對建立資訊結構很有用。新功能 (例如受管理的中繼資料、字詞組和中繼資料導覽) 使中繼資料變得非常有用，而且對擷取內容很重要。因為大型清單上會封鎖修改內容類型和欄之類的作業，所以事先規劃對中繼資料的需求尤其重要。如果您計劃要使用中繼資料導覽或其他依中繼資料擷取內容的方法，則務必在設計階段，規劃內容類型及其將會有的欄。

在大部分大型清單案例中，中繼資料不僅有用，也是使用者使用系統的必備要件。套用中繼資料的方式主要有三種：內建在系統程序中、自訂設定和程式碼，以及由使用者手動套用。若要用欄來擷取內容，大部分項目應該要有為該欄指定的值。這使得規劃哪些欄要用於導覽，以及如何填入中繼資料變得很重要。確保套用正確中繼資料的唯一方法，就是使用內建程序和自訂。例如，因為每個項目都有內容類型，所以如果使用內容類型來將文件分類，則每個項目都會有這個中繼資料，這樣可以方便依內容類型來篩選。

內容類型

內容的最基本分類應該要有內容類型。如果您以中繼資料來將內容分類 (例如文件或項目類型)，則應考慮將該分類用於內容類型。除了與工作流程和範本相關聯，內容類型還可讓您定義與內容類型相關聯的欄。只有一個範本可以與內容類型相關聯，而這就是您使用文件庫中的 [新增文件] 功能表來建立新的內容類型執行個體時，所使用的範本。

您可以將範本用於 Microsoft Word、Microsoft PowerPoint 和 Excel 中的檔案格式，以及其他產品。當使用者建立新的內容類型執行個體時，會使用特定用戶端應用程式，利用範本來開始編寫。當內容上傳之後，使用者就可以從可用的內容類型中選取。內容類型應該清楚、明確，而且每個清單的內容類型數要夠小，使用者在選取所要使用的內容類型時，才不會有困難。

因為內容類型控制著使用者在建立或上傳項目時，所必須填入的中繼資料，所以請考量需要符合商業需求的欄，並且也要儘量減少提交內容的障礙。選取一組好的內容類型，在主要層級將內容分類，可自動幫助導覽。因為每個項目都有內容類型，所以有一個要用於每個項目的樞紐分析要用來篩選。

內容類型建議摘要

• 使用內容類型作為組織內容的最基本方法。

• 使用內容類型來選取該內容類型所需的特定欄。

• 各清單的內容類型應該是很小的數 (不超過 10)，而且應該要夠明確，讓使用者能夠容易了解他們應該使用哪種內容類型。

• 內容類型有提供一個內建欄，每個項目都有該欄的值，可用於篩選及中繼資料導覽。

共同作業大型清單及內容類型的範例：產品規格文件庫

產品開發小組會使用產品規格文件庫來儲存設計規格、測試計劃及其他產品開發項目。在此範例中，會使用下列六種內容類型。所有內容類型都有專案開始日期、專案結束日期、預算、設計小組成員、產品名稱及產品類型的欄。

• 產品規格 – 包含產品設計細節的 Word 檔案。其他中繼資料包含設計者及最後檢閱日期。

• 測試規格 – 包含產品測試計劃的 Word 檔案。其他中繼資料包含測試者及測試完成狀態。

• 開發計劃 – 包含產品開發計劃的 Word 檔案。

• 腳本 – 用來呈現設計圖樣的 PowerPoint 簡報。

• 成本分析 – Excel 試算表，用來分析開發產品及潛在市場商機的成本。

• 時間表 – Excel 試算表，包含產品開發時程的詳細資料。

在此範例中，使用者可以依內容類型篩選，以尋找產品規格或產品腳本。自訂範本也有助於架構使用者的工作。欄數及內容類型是夠小的數量，可讓使用者輕易地選取適合其工作的選項，但是藉由填入中繼資料，就很容易篩選及尋找內容。

欄

欄數及必要欄數

您可以使用欄來指定項目擁有的中繼資料種類，而且您可以將其標示為隱藏、選用或必要。將隱藏欄用於自動化工作 (例如工作流程)，使用者就無法加以編輯。唯有在絕對必要時，才使用必要欄。例如，將項目路由設定至適當位置或用於導覽時，可能會需要中繼資料屬性。在這些情況下，您不會想要讓使用者將該值留白。為了用作導覽篩選的欄而填入中繼資料的項目愈少，導覽就愈沒有用，因為有許多項目是查詢永遠不會傳回的。

隨著中繼資料欄數增加，使用者就比較不會填入中繼資料，因為還需要另外找出哪些欄適用，然後再指定值。如果您使用大量必要欄，使用者可能就很難採用，因為需要很長的時間上傳內容。在非常開放及共同作業的案例中，這是不利的。但是隨著內容的值和建立該內容的工作增加，使用者比較可能會花時間填入適當的欄位，尤其是當此作業不常發生時。

在設計階段期間，您應考量執行必要作業及擷取內容時，需要什麼中繼資料、預估使用者需要花多少時間來填入該中繼資料，並評估對使用者的影響。如果使用者因為建立內容的負荷太高而不採用該系統，以後會很難重新架構系統。

欄位類型及單值對多值欄位

在選擇欄時的一項考量，就是欄類型，以及是否應為多值。在受管理的中繼資料欄位上查詢，會比在選擇欄上查詢有效率，所以您可能會想要考慮使用受管理的中繼資料欄位，而不使用選擇欄位。像受管理的中繼資料及人員或群組之類的欄可支援多值。在多值欄上查詢不像在單值欄上查詢那麼有效率。

欄和內容類型通常是在大型清單分類及擷取內容的中心元件。欄和內容類型的清單應該在規劃程序期間就已經準備好了。新增至清單的欄數內容類型會以微妙的方式影響效能。新增至單一清單的特定類型欄數會造成列換行。如需詳細資訊，請參閱本文稍早的＜列換行＞。

共同作業大型清單及欄的範例：產品規格文件庫

本節說明此範例中使用的欄，如下所示：

• SharePoint Server 2010 自動維護的欄：[識別碼]、[內容類型]、[修改時間]、[建立時間]、[修改者]、[建立者]、[文件識別碼]

• 自訂維護的欄：

  • 依 [產品類型] 及 [產品小組] 的資料夾維護的中繼資料預設值 (每個 [產品類型] 都有一個資料夾，而每個 [產品類型] 資料夾都有多個 [產品小組] 資料夾)

  • 工作流程更新：[核准狀態]、[完成的專案]

• 使用者維護的欄：[設計者]、[測試者]、[最後檢閱日期]

• 適用於導覽的欄：[內容類型]、[產品類型]、[產品小組]

• 用於追蹤狀態，也適用於導覽的欄：[最後檢閱日期]、[核准狀態]、[完成的專案]

• 有助於導覽的欄：[設計者]、[測試者]、[產品名稱]、[修改時間]、[修改者]

欄建議摘要

• 儘量減少可填入的欄數。

• 謹慎選取要用於系統程序及導覽的欄。考量將會需要哪些欄位，並儘量減少必要欄位數。

• 必要欄位應該用在需要用於導覽時，例如對特定欄位使用內容查詢網頁組件。必要欄位也應該要用於管理，例如在使用者必須指定的日期欄位上指定保留動作。

• 因為在單值欄上查詢比在多值欄快，所以請嘗試讓欄單值，除非有需要多值。

清單上的特定欄總數會造成列換行，進而降低效能。儘量減少大型清單上的欄數，並避免列換行 (可能的話)。

資料夾

您應謹慎考量如何將內容組織至資料夾中。使用資料夾的主要方式有三種：

• 按邏輯將內容組織在資料夾中。例如，依照簽署合約的年份或月份，將合約組織在資料夾中，或是依照建立發票的日期，將發票組織在資料夾中。在此案例中，使用者可以輕易導覽整個資料夾結構，或使用中繼資料來尋找文件。此外，也容易將文件自動路由設定至正確的資料夾。當新增的項目超過限制時，可以使用內容組合管理提供的功能來建立子資料夾，以限制單一資料夾中的項目數量。

• 針對保留及權限或其他管理功能，將內容組織在資料夾中。例如，較少使用者可以存取的機密文件資料夾，或是位置型的保留，讓文件依據其資料夾，有不同的保留排程。在此案例，使用者導覽可能會比較困難，因為使用者只要可以存取文件，可能就不在乎文件在哪了。中繼資料導覽及搜尋是尋找文件的首要方法，而不是使用資料夾結構。

• 將內容組織至資料夾中，可幫助使用者依主題或類別導覽。許多使用者都習慣用資料夾導覽。針對特定應用程式，保留資料夾結構，讓使用者方便導覽可能很重要。在此案例中，使用者通常了解資料夾結構，而且知道要在哪裡尋找及放置文件。中繼資料導覽及搜尋可與此方法組合使用。

SharePoint Server 2010 中的改善功能讓您在使用資料夾時有更大的彈性，也比較不需依賴效能考量。藉由使用受管理的中繼資料及中繼資料導覽，使用者可以在中繼資料上輕鬆篩選，而不需導覽整個資料夾。這樣可以讓您針對管理目的 (例如權限或原則) 來組織內容，而不只是為了使用者導覽。例如，您可以有一個機密資料的資料夾，僅供某些員工存取，另一個資料夾可供所有員工存取。您可以為資料夾指定不同權限，然後使用內容組合管理，依據中繼資料，自動將內容移至適當的資料夾。您還是可以選擇將資料夾導覽與中繼資料導覽組合使用。

使用內容組合管理功能，可依據內容類型及中繼資料，自動將內容移到資料夾中，而不需使用者決定要將內容放在哪裡。此外，當某個資料夾達到指定的項目限制時，內容組合管理可用來自動建立新的資料夾。您必須考量到，如果項目沒有組織在資料夾 (任何資料夾根目錄中都沒有超過清單檢視臨界值的項目數) 中，則在大型清單上使用 [在檔案總管中開啟] (WebDAV) 無效。

資料夾型檢視及中繼資料型檢視在效能上非常相似。從邏輯和使用者經驗的觀點來看，使用資料夾來劃分內容是明智。中繼資料導覽會執行遞迴查詢，因此所有項目都會在資料夾外面傳回。如果這是擷取內容的主要方法，資料夾結構也許就不重要了。

下圖顯示使用各種類型的檢視來存取相同的項目數，所進行的測試結果。所有檢視都傳回 1,000 筆結果。此圖顯示隨著清單大小增加，這些檢視個別的每秒要求數。結果顯示，隨著清單大小增加，資料夾和索引檢視的效能仍相對不變，雖然清單大小較小，資料夾會有較佳的效能。針對大部分大型清單，資料夾與索引檢視會組合使用，所以效能差異應該不會指定要使用資料夾還是索引來擷取資料。

資料夾建議摘要

• 規劃如何將項目組織在資料夾中。項目可以自動或手動移動。

• 像中繼資料導覽之類的功能會比較不需要限制資料夾中的項目數。

• 組合使用中繼資料導覽與資料夾導覽。因此，資料夾可用來管理原則和保留，而不只是用來組織內容以供擷取。

• 當它提供最佳使用者經驗時，請考慮將內容組織在資料夾中，以幫助導覽，即使與其他導覽選項組合使用也一樣。

• 使用內容組合管理，依據中繼資料自動將文件移到資料夾中時，請考慮啟用該選項，以在達到特定限制時，在子資料夾中建立額外的項目。

• 如果您計劃使用 [在檔案總管中開啟] (WebDAV)，您必須將項目組織在資料夾中 (任何特定資料夾根目錄中都沒有超過清單檢視臨界值的項目數)。

• 若要擷取清單檢視中的內容，您必須使用中繼資料導覽及索引 (如果您不使用資料夾)。

共同作業大型清單及資料夾的範例：產品規格文件庫

在產品規格文件庫中，資料夾可用來幫助導覽，以及有邏輯地放置內容。使用者可以清楚知道應該使用哪個資料夾來建立新的產品規格。每個產品類型都有一個資料夾，而每個產品類型都有多個資料夾用於每個產品小組。每個產品小組針對其設計的每項產品，各有一個文件集，而產品專屬的文件會儲存在文件集中。這會建立看起來像下面的結構：

• Downhill Skis – 產品類型 (資料夾)

  • Racing Skis – 產品小組 (資料夾)

    Super Faster Downhill Racer X – 產品 (文件集)

您可以為每個資料夾設定中繼資料預設值，這樣可以讓文件庫使用者很容易使用資料夾來尋找內容。

大型封存及資料夾的範例：記錄中心

記錄中心網站可用來長期存放為了符合法律而必須保留的項目，但不會再主動修改內容。在此案例中，項目會自動路由設定至兩個資料夾中：限制及機密。限制資料夾有嚴格的權限，只有少數人可以存取，而且文件必須保留 10 年。機密資料夾可允許比限制資料夾更多的存取，而且其中的文件必須保留 7 年。如此有助於降低唯一權限數，也比較容易管理權限，因為項目是從適當的資料夾接收其權限。進入記錄中心網站的所有項目都會依據中繼資料，路由設定至根、機密或限制資料夾。

索引

您可以為每個清單建立 20 個索引 (不可設定的限制)，包括複合索引，以及依預設將欄編製索引的 SharePoint Server 2010 功能。新增索引至清單對效能幾乎沒有影響。不過，確實會影響某些作業，例如新增和更新。您應避免使用不必要的索引，因為未使用的索引會對效能造成少許的不良影響，而且有些 SharePoint Server 2010 功能在啟用時會新增索引。例如，如果您使用到期及 eDiscovery 功能，SharePoint Server 2010 需要至少三個索引空位。請考慮保留至少三個索引空位，以免您以後必須建立新的索引。

SharePoint Server 2010 會使用它自己的索引機制來使用其資料庫資料表結構。修改清單的設定，以在 SharePoint Server 中建立索引。

在規劃索引時，請考量下列事項：

• 需要索引，以在高於清單檢視臨界值的清單上執行篩選。

• 謹慎規劃要建立哪個單一及複合索引，因為有 20 個索引的限制。

• 為 SharePoint Server 2010 功能保留索引空位，可能會需要建立 [eDiscovery] 和 [資訊管理原則保留] 之類的欄。

• 當您使用單一欄位以內容查詢網頁組件 (含篩選的檢視) 進行篩選時，以及當您使用中繼資料導覽階層和常用作單一篩選的篩選時，建立單一索引。

• 建立複合索引來進行查詢，使用兩欄來篩選，通常傳回的項目數會個別超過清單檢視臨界值，但會選取在一起。

• 索引對某些作業的效能會有不良影響，例如新增文件或編輯屬性。因此，只有在必要時才建立索引。

謹慎規劃索引

清單有 20 個索引的固定限制，而索引欄對大型清單非常重要。因此，您必須謹慎選取單一及複合索引。有數項功能會使用索引。例如，中繼資料導覽功能會自動為所設定的導覽階層和索引鍵篩選編製索引。您應該在對導覽及資訊結構篩選很重要的欄上建立索引。

自動建立的索引

SharePoint Server 功能會建立對清單索引限制不利的索引。下表提供在會新增索引欄之文件庫中常見的 SharePoint Server 2010 功能清單。

欄	功能	使用方式
保留和記錄狀態	就地記錄管理或管理和 eDiscovery	當「就地記錄管理」網站集合功能或「管理和 eDiscovery」功能啟用，且項目宣告為記錄或保留在清單中時，就會新增此欄並編製索引。
到期日、內容類型	資訊管理原則	在新增至清單的內容類型上為資訊管理原則啟用保留時，或是當清單上啟用位置型保留時，就會新增這兩欄並編製索引。

何時建立單一及複合索引

中繼資料導覽功能會自動為中繼資料導覽設定頁面上選取的階層和索引鍵篩選欄建立適當的索引。針對所有階層樹狀欄位，以及針對部分較有選擇性的索引鍵篩選類型，會建立單一索引，這樣一來，當它們單獨使用時，就可以傳回索引的結果及部分結果。針對所有支援的階層與索引鍵篩選組合，會建立複合索引，以在樹狀目錄篩選與索引鍵篩選同時使用時，以充分擴大選擇性。

如果清單中有許多您要篩選的欄，您可能需要手動管理索引，以避免達到索引限制。如果永遠不會使用特定的導覽階層與索引鍵篩選組合，則考慮不要建立複合索引，以減少索引數。當您建立這些索引時，務必在有選擇性，而且可以在清單檢視中單獨使用的欄上選擇單一索引 (作為在選擇另一個篩選之前套用的唯一篩選或第一個篩選)。當中繼資料導覽或自訂查詢中常會同時使用兩個篩選時，以及當一個索引本身的選擇性不高時，就應該使用複合索引。針對用來以清單檢視、網頁組件及其他資料存取方法進行篩選的欄建立索引。

可能會有多個索引無用的狀況。想想您在 [部門] 及 [內容類型] 這兩欄上進行篩選的狀況。因為這是 AND 作業，所以只會傳回 [部門] 及 [內容類型] 篩選相符的交集。這表示在執行查詢時，會先傳回符合 [部門] 篩選的所有項目，然後才是 [內容類型] 篩選的那些項目。如果只有 10 個項目符合特定部門，您就會有小到連 [內容類型] 上的索引都無所謂的資料集。如果有數千個項目符合 [部門] 的值，則應使用複合索引。

複合索引可讓您在允許更有效率查詢的兩欄上建立索引。在兩欄上執行 AND 作業時，應使用複合索引。中繼資料導覽是使用複合索引的唯一現成 SharePoint Server 功能。當中繼資料導覽功能啟用時，會使用重試及遞補邏輯，即使沒有為清單設定中繼資料導覽控制項也一樣。除非是中繼資料導覽查詢，否則檢視不會使用複合索引。

索引的效能效果

在單一容器項目數超過清單檢視臨界值的清單上，需要索引來執行查詢，索引可以大幅改善效能。雖然大型清單上需要索引來執行有效率的查詢，而且可以大幅改善查詢效能，但索引對其他作業會有不良影響，因為索引需要維護。在建立、更新及刪除項目之後，該項目參與的任何索引也都必須更新。我們曾在含有 10,000 個項目的清單上上傳、更新及刪除作業，以進行測試，結果顯示 0 到 20 個索引之間的效用低於 10%。

索引建立

根據預設，中繼資料導覽功能會自動建立單一及複合索引。您可以從中繼資料導覽設定頁面停用此選項。中繼資料導覽功能會自動為每個受支援的欄類型建立單一索引，並為每個受支援的導覽階層與索引鍵篩選組合建立複合索引。不會自動為兩個索引鍵篩選的組合建立複合索引，但您可以手動建立。中繼資料導覽會自動為支援索引的大部分欄類型建立單一及複合索引。針對值較少且不能單獨選取的索引鍵篩選類型，不會自動為其建立單一索引。其中包括 [是/否]、單值選擇或內容類型欄，但索引受支援，而且可以手動建立。

為單一索引支援的欄

下表提供中繼資料導覽會自動建立之索引的相關資訊。中繼資料導覽會針對支援建立索引的所有欄，建立單值索引。

欄類型	建立的索引
導覽階層
單值受管理的中繼資料	是
多值受管理的中繼資料	否 (系統編製索引為多值)
內容類型識別碼	是
單值選擇	是
資料夾	否 (系統依資料夾編製索引)
索引鍵篩選
單值受管理的中繼資料	是
多值受管理的中繼資料	否 (系統編製索引為多值)
內容類型識別碼	否 (可手動建立)
單值選擇	否 (可手動建立)
多值選擇	否 (不支援為索引)
數字	是
日期	是
是/否	否 (可手動建立)
貨幣	是
使用者 (單值)	是
使用者 (多值)*	否 (系統編製索引為多值)
所有標籤	否 (系統編製索引為多值。針對項目中的所有受管理中繼資料進行特別篩選)

自動建立的複合索引

利用中繼資料導覽功能，使用者可以同時選取導覽階層和索引鍵篩選。中繼資料導覽功能會自動為所有受支援的導覽階層與索引鍵篩選組合建立複合索引。下表顯示所支援的組合。

導覽階層	單值受管理的中繼資料	多值受管理的中繼資料	內容類型識別碼	單一選擇	資料夾
索引鍵篩選
單值受管理的中繼資料	是	否	是	否	否
多值受管理的中繼資料	否	否	否	否	否
內容類型識別碼	是	否	否	否	否
單值選擇	否	否	否	否	否
多值選擇	否	否	否	否	否
數字	是	否	是	否	否
日期	是	否	是	否	否
使用者 (單一)	是	否	是	否	否
所有標籤	否	否	否	否	否
是/否	是	否	是	否	否
貨幣	是	否	是	否	否
使用者 (多值)	否	否	否	否	否

中繼資料選擇性

隨著清單的大小增加，中繼資料選擇性的重要性也會增加。以下建議仍適用於任何清單大小。不過，對較小的清單而言，可能就沒那麼重要了。

選擇性是傳回查詢結果時，所必須考量的項目數。這有兩個層面：實際選擇性 (符合查詢搜尋條件的結果總數)，以及節流選擇性 (在套用適用於索引欄的條件之後，所需考量的結果數)。實際選擇性是您在考慮使用者經驗時的主要考量。節流選擇性是您在考慮對 SQL Server 執行個體的效用時的主要考量。

若要有效使用中繼資料導覽及其他清單篩選機制，用來篩選的中繼資料必須有選擇性。根據預設，清單檢視會顯示 30 個項目，讓使用者可以快速掃描結果，找到您要尋找的項目。如果查詢傳回超過 30 筆結果，使用者就必須使用分頁來尋找結果。如果您是使用內容查詢網頁組件，則 10 到 15 是常見的結果數。如果結果多於此數，則不會顯示額外的結果。當查詢有數百筆結果時，就會很難找到您要尋找的項目。選擇性對於幫助防止作業超過清單檢視臨界值也很重要，在中繼資料導覽案例中，結果會遞補，而不會傳回所有結果。

內容組合管理及自動平衡

內容組合管理可說是在文件存放庫中組織內容的中心元件。使用內容組合管理的存放庫有一個提交過程，當其處於最後狀態時，使用者會上傳文件。可使用內容組合管理的部分案例如下：

• 根據網站之間及網站內部的中繼資料，自動路由設定文件。

• 自動路由設定文件及建立新資料夾，例如以日、月、年為依據的資料夾。

• 自動平衡資料夾中的項目數。

資料存取及擷取

大部分大型清單的主要目的就是儲存內容，以供擷取。規劃使用者如何擷取內容是很重要的，因為這對大型清單的效能以及大型清單實作的成功影響最大。有數項功能 (包括搜尋、中繼資料導覽、內容查詢網頁組件和檢視) 全都可以用來幫助使用者擷取內容。自訂解決方案 (例如對資料進行查詢的自訂網頁組件) 也很常使用。請事先規劃網站的組織方式。您可以使用中央登陸頁面 (例如文件中心網站的首頁) 來彙總內容，並提供大型清單的進入點。您也可以使用發佈頁面來建立網站，讓每一頁涵蓋各種主題，然後再使用網頁組件，將相關文件或項目從大型清單拉出。資料存取及擷取的考量事項如下：

• 搜尋、內容查詢網頁組件、中繼資料導覽、清單檢視及自訂網頁組件的任何組合都可以使用。

• 事先規劃擷取內容的方式，以及將會使用哪幾欄來篩選和排序。

• 規劃基本頁面模型。考量是否要在文件庫中執行所有工作，或是要有登陸頁面，還是要有連結至相關內容的多頁面模型。

資料存取方法

有三種主要 SharePoint Server 2010 功能，只要簡單的設定，即可用來查詢及篩選清單資料：清單檢視與中繼資料導覽、內容查詢網頁組件以及搜尋。還有其他選項可使用自訂程式碼來查詢清單；本文沒有說明那些選項。

• 檢視可讓您設定所顯示的欄。清單資料有各種顯示方法。您可以設定檢視，依欄篩選及排序結果。

  • 中繼資料導覽是 SharePoint Server 2010 清單檢視的篩選控制項。設定中繼資料導覽之後，您可以選取中繼資料階層及索引鍵篩選，以動態篩選清單檢視中顯示的結果。

• 內容查詢網頁組件會顯示 SharePoint Server 2010 清單中的資料。查詢可供設定，以從一或多個清單傳回結果。根據預設，內容查詢網頁組件是快取的。不過，它可以是非快取的。

• 搜尋方塊或搜尋結果網頁組件可用來傳回搜尋結果。您可以將這些結果限定在特定清單，並使用搜尋中繼資料精簡控制項來執行引導式搜尋。

下表列出查詢方法及其使用方式。

查詢方法	使用方式
清單檢視及中繼資料導覽	清單檢視一律存取 SQL Server 後端資料庫，這會造成對效能影響最大的查詢，並導致較高的 SQL Server 負載。請使用清單檢視來提供較多選項，以與文件互動 (存回、取出、編輯屬性)，以及即時存取資料。
內容查詢網頁組件	內容查詢網頁組件使用入口網站地圖提供者來快取查詢，並轉譯最少量的 HTML，所以查詢及轉譯時間最快。使用內容查詢網頁組件進行動態導覽，並且在單一頁面上執行多項查詢。
內容查詢網頁組件非快取	為提供即時存取資料，內容查詢網頁組件可以直接查詢資料庫。當無法快取查詢時、需要即時更新時，以及針對一小時存取不到一次頁面，請使用此設定，這樣就永遠不會填入快取。初始載入快取的內容查詢網頁組件會造成額外負荷。
搜尋	使用搜尋查詢來將讀取卸載至較容易擴充以及最佳化讀取效能的伺服器基礎結構。搜尋查詢可設定為使用靜態查詢，或者您可以允許使用者指定搜尋查詢。

內容查詢網頁組件

下表顯示使用內容查詢網頁組件的各種優缺點。

優點	缺點
作為導覽元件非常好，例如，相關的文件或頁面的連結。 簡易設定即可顯示不同欄。 可以在一個頁面上輕易使用多個內容查詢網頁組件。 與搜尋和清單檢視相較，轉譯速度最快。 根據預設快取，降低 SQL Server 負載。	只能顯示有限的屬性數。 連結只會直接前往項目，例如文件、頁面或清單項目本身。 您不能執行清單動作。

內容查詢網頁組件可用來從清單擷取內容。其可用於頁面、文件及清單項目。根據預設，內容查詢網頁組件是快取的，可提供較佳效能，對 SQL Server 資源影響較小。預設快取設定為 30 分鐘。因此，資料可以維持相當新。不過，這也表示內容查詢網頁組件使用的 SQL Server 資源比搜尋查詢多。因為內容查詢網頁組件轉譯最少量的 HTML，所以頁面轉譯較快，而且可以在單一頁面上設定多個內容查詢網頁組件。快取的內容查詢網頁組件會隨著清單大小增加，提供快速資料存取。非快取的內容查詢網頁組件有和相似清單檢視查詢幾乎一模一樣的延遲。

內容查詢網頁組件應該用作導覽元件，並且在頁面上提供內容彙總。例如，您可以使用頁面來提供位於文件庫中之內容的概觀，然後使用內容查詢網頁組件傳回相關頁面及文件。部分其他範例包括目前使用者修改的項目、最新項目，以及評分最高的項目。內容查詢網頁組件可用在高讀取案例中，其中大部分使用者都不需要執行清單動作，例如存回、取出或管理版本。下圖是顯示評分最高之文件的內容查詢網頁組件。

內容查詢網頁組件可用來存取內容，而不需輸入清單檢視。使用者可能會有他們經常存取的少量內容，或是要追蹤的項目。在文件中心網站範本上，依預設會使用三個內容查詢網頁組件：一個會傳回登入使用者修改的項目，另一個用於評分最高的文件，第三個用於最新的文件。這三個內容查詢網頁組件組合在一起可提供登陸頁面，提供使用者可能經常存取或最感興趣的內容。這可以支援探索新內容，以及快速存取經常使用的文件。另一個範例是建立我的最愛清單，讓使用者可以標示要追蹤的內容，然後使用內容查詢網頁組件來傳回我的最愛清單，讓使用者可以快速存取他們經常使用的內容，而不需存取清單本身。

當您使用含有大型清單的內容查詢網頁組件時，需要考量一些重要事項，以正確傳回結果，而不會被清單檢視臨界值封鎖。必須使用索引欄，將項目篩選至低於清單檢視臨界值的數量。當其中一個清單是大型清單時，建議您不要使用跨清單查詢。如果在跨清單查詢中考量的項目總數大於稽核者及管理員的清單檢視臨界值 (預設值為 20,000)，則會封鎖作業。

內容查詢網頁組件建議摘要

• 使用內容查詢網頁組件來傳回使用者經常存取、感興趣或是有助於使用者探索內容的項目。

• 當您對大型清單使用內容查詢網頁組件時，應篩選項目，這樣查詢才不會超過清單檢視臨界值。

• 您應該只使用含索引的欄來進行篩選。

• 如果所考量的項目總數大於稽核者及管理員的清單檢視臨界值 (預設值為 20,000)，請勿使用內容查詢網頁組件來查詢多個清單。

• 使用快取以加快載入時間，並減少 SQL Server 負載。

搜尋網頁組件

下表顯示搜尋網頁組件的各種優缺點。

優點	缺點
從執行 SQL Server 的電腦卸載查詢，以搜尋較容易擴充的伺服器。 搜尋查詢及索引伺服器比直接查詢 SQL Server 較容易擴充，效能也較好。 結果是依據文件的全文搜尋，而不只是依據中繼資料。 文字摘要提供的結果相關資訊比內容查詢網頁組件多。	結果是最不新的，最多只和最新的編目一樣新。 結果不顯示欄值。 您不能執行清單動作。

搜尋查詢擴充得比直接存取 SQL Server 資源好，因為搜尋已針對高讀取案例最佳化，而且與擴充 SQL Server 執行個體相較，擴充至多個搜尋索引和查詢伺服器會比較容易。您可以使用預先設定的搜尋網頁組件、搜尋方塊或組合，以幫助使用者擷取內容。搜尋查詢提供將查詢卸載至搜尋索引的方法，以降低 SQL Server 負載。與內容查詢網頁組件或清單檢視查詢相較，搜尋查詢受清單大小的影響也較小。

您可以在任何案例中使用搜尋，以顯示預先設定或使用者指定查詢的結果。搜尋在高擴充點提供最佳效能。如果必須在項目上執行清單動作，或是如果因為結果只和最新的編目一樣新，而必須即時顯示資料，則不應使用搜尋。下表顯示三個可使用的搜尋網頁組件。

搜尋網頁組件	描述
核心結果網頁組件	含有分頁的完整結果，以及功能最完整的網頁組件。可取得系統或使用者指定的查詢。
同盟結果網頁組件	一小組結果集，並有選用性的連結可存取完整結果。
搜尋方塊網頁組件	用來取得使用者輸入以進行查詢的網頁組件。

清單檢視

下表顯示使用清單檢視的各種優缺點。

優點	缺點
像存回、取出和編輯屬性之類的清單檢視動作，可用來與文件互動。 易於自訂檢視及顯示不同欄。 動態篩選和即時排序結果具有高度互動性。	對延遲和輸送量效能產生的不良影響最大。 最慢轉譯時間 最佳使用者經驗是每頁只有一個清單檢視網頁組件。

清單檢視及中繼資料導覽可在使用資料夾及/或索引的大型文件庫中，支援內容擷取。以清單檢視來查詢會即時執行，並且會直接查詢 SQL Server 資料庫。這可提供最新結果。不過，這對效能的影響也最大。若為大型清單大小，整體輸送量會減少，而作業的延遲會增加。清單檢視也會轉譯最多內容讓頁面載入。因此，使用清單檢視時，頁面轉譯時間通常比較長。

當您必須能夠在項目上執行清單檢視動作時，應使用中繼資料導覽及清單檢視。清單檢視可說是在低讀取案例使用清單的主要方法。在有許多讀取作業的案例中，您可能會想要考慮以其他查詢方法作為存取清單資料的主要方法。

檢視設定

檢視設定建議摘要

• 謹慎選取檢視中使用的欄。欄愈多表示要轉譯的資料愈多，進而增加頁面載入時間。在頁面載入時間與最佳使用者經驗之間要有所取捨。

• 儘量減少查閱欄數量，例如受管理的中繼資料，以及檢視中的人員與群組，因為這會導致與其他資料庫資料表連接，並增加資料庫負載。

• 不要為欄使用總計。

• 如果不是使用索引欄來篩選檢視，請選取顯示資料夾中項目的選項，並確定個別資料夾的項目數沒有超過清單檢視臨界值。

• 檢視應該在索引欄上進行篩選，以減少傳回的項目數，讓該數低於清單檢視臨界值 (尤其是如果沒有子資料夾，或如果資料夾包含的項目數超過清單檢視臨界值)。

• 啟用中繼資料導覽功能，以傳回查詢的最新結果，否則清單檢視臨界值會阻止該查詢。根據預設，幾乎所有網站都有啟用此功能。

• 如果您是將篩選的檢視與中繼資料導覽組合使用，請考慮使用每一位置檢視來為中繼資料導覽樞紐分析建立未篩選的檢視，這樣就會傳回所有結果。

欄數及查閱欄數

檢視是最常用來存取清單資料的方法。應謹慎選取檢視，以最佳化使用者尋找內容以及符合效能需求的方式。針對大型清單，請特別注意檢視的設定方式。我們只建議標準檢視和自訂檢視。資料工作表、甘特圖及行事曆檢視不建議用在超過清單檢視臨界值的清單上，因為清單檢視臨界值會將其封鎖。檢視的欄數應該愈少愈好，但請特別小心查閱欄數 (受管理的中繼資料、人員與群組及查閱類型)，因為查閱會在其他表格上執行連接，這樣會影響效能。

欄篩選及總計

SharePoint Server 2010 中的新清單檢視臨界值呈現出必須將檢視如何用於大型清單的主要變更。如果檢視嘗試傳回大於清單檢視臨界值的結果，使用者就會收到錯誤。清單檢視臨界值一律會封鎖在大型清單上使用總計。因此，請勿加以使用。必須掃描的項目數很重要，不需要是所傳回的列數。如果檢視有一項篩選，其中欄 [色彩] = [紅色]，而 [色彩] 不是索引欄，這樣就會被阻止了。即使符合此查詢的只有 100 個項目，但如果清單中有 10,000 個項目，查詢就必須掃描 10,000 個項目。在此情況下，當使用者嘗試存取檢視時，就會收到錯誤。若要解決這個問題，您可以使用資料夾、篩選和索引，以及中繼資料導覽。

資料夾

如果清單已組織，以致於沒有資料夾包含超過清單檢視臨界值的項目數，則您可以選取顯示資料夾中項目的選項。應避免顯示資料夾外的所有項目，除非您有現成的機制可將結果篩選至少於清單檢視臨界值的數量。

索引

在稍早的範例中，在 [色彩] 欄上執行查詢失敗，因為其未編製索引。若要解決這個問題，可以將 [色彩] 欄編製索引，如果值夠明確，查詢就會運作。如果只有 100 個紅色項目，這就會運作。不過，如果符合的項目數超過清單檢視臨界值，則即使編製索引，還是會被封鎖。根據預設，識別碼欄位、資料夾結構及多值查閱會在系統中編製索引。所建立及用於篩選的任何新欄都必須要有手動建立的索引。

範例檢視

最近變更的項目

[最近變更的項目] 檢視可用來顯示最新的變更項目。當使用者經常從最近修改的各種來源存取內容時，可將其用於預設檢視。設定此檢視很容易，因為它使用每個項目都一定會設定的系統中繼資料。針對大型清單，您必須將項目限制設為低於清單檢視臨界值的數量，或是將結果篩選至低於清單檢視臨界值的數量。若要建立此檢視，您必須將修改的欄位編製索引，並以遞減順序排序。為 [修改日期] 欄指定篩選，並使用公式 [Today-x]，其中 x 是所要顯示之資料的天數值。選取大於或等於選項。公式 [Today-x] 應該會傳回低於清單檢視臨界值的項目數量。

我的項目

[我的項目] 檢視可用在使用者經常存取自有文件的存放庫中。此檢視很容易設定，因為它使用每個項目都一定會設定的系統中繼資料。在此檢視中，您可以依 [修改者] 及/或 [建立者] 欄來篩選。若要在篩選中建立此檢視 ，請選取 [修改者] 欄，將值設為 [ME]，然後在 [建立者] 欄上，以 OR 設定第二個篩選，值也是設為 [ME]。當有多個使用者編輯相同文件時，除了使用 [修改者] 欄外，還應該使用 [建立者] 欄。[修改者] 不是多使用者欄。因此，這個檢視不一定會顯示使用者曾修改過的所有文件。在此範例中，這兩欄都應編製索引，因為該作業是 OR 作業。

總結

SharePoint Server 2010 提供新的改善功能，可增強使用大型清單的使用者經驗及效能。節流及限制可以為其他使用者保護伺服器陣列的效能，並防止作業消耗過多的 SQL Server 資源。中繼資料增強功能及中繼資料導覽可強化擷取清單資料的經驗，而內容查詢網頁組件、搜尋和清單檢視可以設定來使用大型清單。仍需謹慎規劃，以針對您的需求建立正確的解決方案。不過，將設計效能良好的現成解決方案加以設定，可以快速開發大型清單。

See Also

Other Resources

資源中心：SharePoint Server 2010 的容量管理