设计大型列表并最大限度地提高列表性能 (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
性能度量和测试方法
限制
其他限制
大型列表与常规列表的区别
大型列表设计和实现
结束语
了解查询方法
有三种可用于访问列表数据的主要方法：带元数据导航的列表视图、内容查询 Web 部件和搜索。每种方法都有优缺点和特定用途。
列表视图和元数据导航
列表视图总是访问 Microsoft SQL Server 数据库。与其他方法相比，此方法会导致对 SQL Server 资源的查询性能更低且负载更大。此外，列表视图将会呈现大部分的 HTML，从而导致页面加载速度比其他方法更慢。列表视图为用户在配置视图、动态筛选数据以及对文档执行操作（例如，管理版本和编辑属性）上提供了最佳体验。可以使用元数据导航筛选列表视图结果。当您必须获得各种列数据和对列表项操作的访问权时，应使用列表视图。在需要进行大量读取和查询操作的方案中，应考虑使用其他查询方法。
内容查询 Web 部件
内容查询 Web 部件显示了静态配置的数据视图，该数据视图将由门户网站地图提供程序缓存以提供更佳性能。内容查询 Web 部件呈现了最少的 HTML 并进行了缓存。这会加快页面加载速度，使您能够在一个页面上更轻松地进行多个查询。内容查询 Web 部件应用于显示指向相关列表项、文档或页面的链接。虽然也可以将内容查询 Web 部件配置为不进行缓存，但应仅在吞吐量要求较低的页面上或缓存无用的页面（例如，查询将基于访问页面的用户发生更改的页面）上使用此配置。
搜索
搜索 Web 部件可用于将查询卸载到为查找内容（与编辑属性和实时查看更新相对）而优化的系统。搜索 Web 部件可配置为使用静态查询或用户指定的查询。搜索 Web 部件具有良好的性能。但是，该数据仅与最新爬网保持一致。这意味着，所获结果要旧于来自列表视图和内容查询 Web 部件的结果。
大型列表方案示例
有一些常见的大型列表方案，您将根据方案做出不同的设计决策。例如，在协作大型列表方案中，用户会频繁添加内容和更新属性。在此类方案中，您不希望列表大小增加到几百万个项目，因为这将难以筛选内容且内容会频繁更新或更改。如果您使用的是非结构化的文档库，本文可帮助您了解可保护 SQL Server 性能的限制。下表显示了大型列表方案的注意事项。
| 方案 | 列表大小 | 管理 | 读取/更新/添加率 | 新内容 | 用户 |
|---|---|---|---|---|---|
非结构化的文档库 |
数百个 |
无管理者 |
较多的读取操作，添加操作和更新操作均衡 |
手动上载 |
数十个 |
协作大型列表或库 |
数千个 |
非正式的主题所有者 |
较多的读取操作，更新操作多于添加操作 |
手动上载 |
数百个 |
结构化大型存储库 |
数万个 |
专门的内容管理者 |
非常多的读取操作，较少的添加操作，非常少的更新操作 |
提交和上载 |
数万个 |
大规模存档 |
数百万个 |
内容管理者团队 |
较少的读取操作和更新操作，较多的添加操作 |
提交 |
数万个 |
非结构化的文档库
非结构化的文档库经常用于团队或工作组，它通常包含数十个到数百个文档。在不进行规划的情况下，这些库会增大到超过列表视图阈值的大小，这会影响某些操作（如添加列）。可能存在的问题是，如果视图增大到包含 5,000 个以上的项目，则用户可能会遇到列表视图阈值异常。可以通过监视正在接近列表视图阈值的库来减少此情况。（文档库的库设置页上会显示一个计量，指示文档库正在接近列表视图阈值。）
此方案通常包含数十个甚至是数百个用户，但包含的并发用户较少。因此，单个库内部的加载很少会出现问题。不过，可能会有很多这些类型的库。因此不要规划支持特定的实例，将重点放在支持这些类型的库更重要。
协作大型列表或库
协作大型列表包含数百个到数千个项目，它被用作大量活动内容的存储。协作大型列表通常包括知识管理解决方案、工程库以及销售和营销宣传材料库。用户会主动添加和编辑内容（大量读取操作和写入操作）。可以将结构和管理置于适当的位置以保持库的条理性。但是，由于用户会执行大量工作，因此可能会发生超过管理员控制范围的事件。这就很容易导致列表以快于预期速度的速度增长或超过所规划的限制。此类存储库可包含数百个或数千个用户，其中有数十个甚至是数百个并发用户。
与结构化存储库或存档相比，协作大型列表更易于进行管理性更改，例如，添加或删除文件夹、添加内容类型或列或重新组织内容。由于列表大小，可通过列表视图阈值来阻止这些操作。
结构化大型存储库
结构化大型存储库包含数千个到数十万个项目。该内容通常为最终内容并由用户或系统进程（如工作流）提交。结构化大型存储库通常用于部门记录存档、价值较高的文档存储和网页上显示的最终文档。该内容通常是结构化的且高度托管，以便更轻松地控制列表的增长。此方案可包含数十个或数百个并发用户和一个有数千个用户的用户群。读取操作的百分比远远高于写入操作的百分比。不过，仍可能存在对内容的更新，并且可能会频繁添加和删除内容。部门或组织的知识管理存储库是一个结构化大型库示例。
在此方案中，在解决方案生效之前，完全了解用户需求并执行全面测试非常重要。因此，在向解决方案中填入大量内容之前，解决方案已相当完整且已定稿。例如，配置适当的元数据导航层次结构和筛选器是提供相应的内容浏览体验所必需的。
大规模存档
大规模存档包含数千个到数百万个项目，这些项目位于单个列表中或分布在多个列表中，或位于多个最高端的网站集中。此方案通常包含较少的读取操作和更新操作，且通常仅用作出于合规性或其他原因必须保留的文档（例如，为符合法律要求而必须保留七年的文档）的长期存储。在此方案中，文档的提交操作和删除操作的高吞吐量很重要。搜索是用来检索内容的主要方法。
大型列表与 SharePoint Server 2010
为 Office SharePoint Server 2007 中的大型列表提供帮助的功能仍可为 SharePoint Server 2010 提供帮助，对这些功能中的许多功能进行了改进以便大规模地提高性能。SharePoint Server 2010 还具有许多新功能，可帮助改进大型列表的性能，并使用户能够更高效地使用大型列表。本节汇总了 SharePoint Server 2010 中的新功能和已改进的功能。
改进的功能
以下各节讨论了已在 SharePoint Server 2010 中改进的 Microsoft Office SharePoint Server 2007 的功能。
内容查询 Web 部件
可以将内容查询 Web 部件配置为对列表、内容类型和列进行筛选来显示结果。可以对结果进行分类并选择要显示的列。这样一来，内容查询 Web 部件便能在网页上显示大型列表内容。通常会对内容查询 Web 部件进行缓存。这可允许更快的页面加载和较小的数据库负载。内容查询 Web 部件在知识管理方案中的一种用法是，在发布页上使用这些部件来显示指向与网页内容相关的文档的链接。
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 网站模板。文档中心网站模板包括一些功能（如预配置的内容查询 Web 部件，用于通过登录用户和已配置元数据导航的文档库返回相关结果）。
记录中心网站模板类似于文档中心网站模板，只不过它具有内容管理器功能（已启用此功能以传送文档）和记录库（向其中添加的项目为自动声明的记录且无法删除）。记录中心网站模板是未启用文档分析器的唯一的现有模板，它保留了已提交内容的保真度。禁用文档分析器会影响某些操作的性能，从而使该模板比其他网站模板更适合大规模文档存储（数千万个项目）。
新功能
本节描述了 SharePoint Server 2010 中的新功能，这些功能可帮助管理大型列表和列表性能。
内容管理器
可在任何网站上使用内容管理器将内容传送到特定文档库、文件夹甚至其他网站。内容管理器可用于基于元数据属性自动创建内容文件夹。用户可以将内容从其他网站提交到内容管理器，而不必担心内容在文件计划中的存储位置。内容管理器可用于平衡各个文件夹中的内容以自动维护每个文件夹的最大大小。当达到指定大小限制时，会创建一个新的子文件夹来包含额外的项目。
元数据导航
元数据导航是一项新的 SharePoint Server 2010 功能，允许用户动态筛选列表以便能找到所需内容。元数据导航使用户能够选择筛选器选项，并以可能最有效的方式执行查询。元数据导航由两部分组成。一个部分是一组导航控件（使用户能够筛选具有导航层次结构和主要筛选器的列表）。另一个部分是重新安排和重试查询的机制。
元数据导航具有重试和回退逻辑，可尝试使用索引有效执行查询。如果某个查询将返回过多结果，该查询会回退并返回一小部分结果以获得更好的性能。如果未发起适当的查询，则会发生回退，并会对一组有限结果执行筛选。元数据导航会自动创建索引。重试、回退和索引管理结合在一起使元数据导航成为有效使用大型列表的非常重要的部分。有两类筛选机制：导航层次关系和主要筛选器。
导航层次结构使用树控件导航文件夹的层次结构、内容类型、选项字段或托管元数据术语集。这使用户能够使用树控件对元数据层次结构进行透视，这种方式与导航文件夹的方式很相似。当用户在层次结构中为某个托管元数据列选择一个项目时，将显示与指定术语或其任何后代子术语匹配的所有项目。这称作“后代包含”并可用于绑定到托管元数据术语集的字段。用户可以再次选择该术语以仅按特定术语进行筛选，而不包含后代子术语。所有元数据导航查询都是递归查询，它们会显示来自列表中的所有文件夹的结果。
主要筛选器可配置为对层次结构中的结果进行额外的筛选。例如，可以将“修改者”列添加为主要筛选器，然后键入用户名以获取“修改者”与输入的用户匹配的结果。有关详细信息，请参阅元数据导航和筛选 (https://go.microsoft.com/fwlink/?linkid=219154&clcid=0x804)。下图显示了元数据导航层次结构和主要筛选器的示例。
.gif "密钥筛选器列表的屏幕截图")
托管元数据
托管元数据是一组新功能，这些功能为 SharePoint Server 添加了更多的信息体系结构功能。托管元数据功能包括一类称为 Managed Metadata Service 的共享服务。Managed Metadata Service 可用于存储可在整个 SharePoint Server 2010 部署中重用的术语集。其中的一些托管元数据功能包括：
支持平面或深度层次结构的术语集
将术语集用作可用属性的托管元数据列类型
可打开（以便任何用户添加新术语）或限制（仅特定用户可管理）的术语集
通过使用托管元数据列和术语集来组织内容，可以使用诸如内容查询 Web 部件和元数据导航这样的功能来帮助用户查找和发现内容。托管元数据还有助于进行常规搜索查询，因为它添加了可用于对文档进行分类的关键字。可在搜索精简面板中使用托管元数据。下图显示了托管元数据导航的示例。
.gif "术语的屏幕截图")
限制
SharePoint Server 2010 引入了多项可配置的限制以帮助维护服务器场性能。现已存在 Web 应用程序级别的可配置的限制。已添加这些限制以便来自单个用户或进程的操作不会对服务器场性能产生负面影响。例如，列表视图阈值是一项限制，用于阻止影响大于特定数目的数目的列表项的查询。
复合索引
索引对于大型列表很重要。现在，可以在 SharePoint Server 2010 中创建复合索引了。通常，在对两个列执行查询时，复合查询会很有用，因为仅对一个列执行一个查询的选择性可能不足。视图不使用复合索引，而元数据导航会使用复合查询。在发生限制情况时，元数据导航逻辑会重试并会对所选筛选条件使用适用的复合查询和单个查询，来查找满足查询要求的完整或部分结果。
开发人员面板
开发人员面板显示每个页面加载的详细诊断信息。默认情况下，该此面板处于关闭状态。不过，可以手动打开该面板或将其配置为总是处于打开状态。在打开开发人员面板后，可以使用它获取有关数据库查询、加载次数和错误的信息。利用开发人员面板，可以更轻松地快速分析和诊断性能问题。下图显示了开发人员面板。在具有大型列表和限制的情况下，开发人员面板中会显示元数据导航功能，左侧的操作树中会显示用于重试的索引的列表和部分结果，而右侧的列表中会显示尝试的不同的索引 SQL Server 查询。
.gif "开发人员仪表板的屏幕截图")
开发人员面板对于调试自定义 Web 部件和查询也很有用。有关如何启用开发人员面板的详细信息，请参阅博客：使用对象模型/Powershell 启用开发人员面板（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=219613&clcid=0x804)（该链接可能指向英文页面）。
内容迭代器
内容迭代器开发人员 API 简化了对大型列表编写代码的过程，它对新的列表视图阈值限制特别重要。内容迭代器是一种方法，用于检索内容以便在小型集中对其执行操作，而不是对整个数据集执行操作。这可阻止操作超过列表视图阈值。
远程 BLOB 存储
默认情况下，SharePoint Server 2010 会将文件（二进制大型对象 (BLOB)）数据存储在 SQL Server 数据库中。内容数据库的大量内容通常是 BLOB 数据。远程 BLOB 存储 (RBS) 允许将此数据存储在 SQL Server 的外部，这可以获得成本较低的存储选项并减小内容数据库大小。远程 BLOB 存储是作为 SQL Server 2008 的加载项功能包纳入的库 API 集。第三方远程 BLOB 存储提供程序是使用远程 BLOB 存储 API 所必需的。
性能度量和测试方法
本节包括对已用于本文讨论的测试的测试方法的说明。在显示数据的地方注明了此方法的偏差。
硬件和服务器场配置
下面的图和表中指定了测试服务器场配置。测试配置的两个方面与大多数实际部署有着显著的区别。具体而言：
NTLM 身份验证用于避免域控制器变成瓶颈。这会实现较小的性能改进。
应用程序服务器包含一个用于日志记录数据库的 SQL Server 实例。这样做可减少对主要 SQL Server 实例产生的负载，因为该日志记录级别远远高于实际部署中的日志记录级别。
.gif "此测试服务器场的拓扑示意图")
| 计算机名称 | 两个 Web 服务器 | 一个应用程序服务器 | 一个数据库服务器 |
|---|---|---|---|
角色 |
前端 Web 服务器 |
应用程序服务器 |
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 GB |
1 GB |
1 GB |
身份验证 |
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 配置 |
|---|---|---|
临时 DB |
1 |
0 |
配置 DB |
1 |
0 |
内容 DB #1 |
1 |
0 |
配置文件 DB |
1 |
0 |
搜索 DB |
1 |
0 |
分类 DB |
1 |
0 |
测试负载
已针对常规操作组合在最佳负载点或绿色区域执行测试。为了测量特定的更改，在变量发生更改的每个点上执行了测试。为了查找最佳负载点，添加了额外的线程以使环境达到饱和，并保持在以下度量之下：
75% 的延迟少于 1 秒
前端 Web 服务器 CPU 使用率低于 50%
SQL Server CPU 使用率低于 50%
应用程序服务器 CPU 使用率低于 50%
失败率低于 0.01%。
测试定义
下表定义了测试，并概述了用于每个测试的过程。
| 测试名称 | 测试说明 |
|---|---|
文档上载 |
上载文档。 编辑并更新该文档的属性。 |
文档上载和传送 |
上载文档。 编辑并更新该文档的属性。 传送符合传送规则的文档。 |
文档下载 |
下载文档。 |
访问文档库 |
访问文档库列表视图页。 |
访问包含内容查询 Web 部件的主页 |
访问包含三个内容查询 Web 部件的文档中心网站主页。 缓存的内容查询 Web 部件返回 15 个最高评级的文档。 缓存的内容查询 Web 部件返回 15 个最新文档。 非缓存的内容查询 Web 部件返回 15 个已由当前用户修改的最新项目。 |
托管元数据回退查询 |
一个返回 5,000 个以上的结果的列表视图查询（按单值托管元数据列筛选这些结果）。 |
托管元数据选择性查询 |
一个返回 1,000 个结果的列表视图查询（按单值托管元数据列筛选这些结果）。 |
内容类型回退查询 |
一个返回 5,000 个以上的结果的列表视图查询（按内容类型筛选这些结果）。 |
内容类型选择性查询 |
一个返回 1,000 个结果的列表视图查询（按内容类型筛选这些结果）。 |
测试组合
每个测试组合均包含不同的组成部分。通过使用 Visual Studio 测试系统执行了这些测试。已填充每个测试的特定数据点，然后测试组合先运行了 2 分钟做准备工作，然后运行了 10 分钟进行数据收集。本文中显示的结果是后 10 分钟收集到的数据的平均值。下表显示了单个测试组合中的每个解决方案所占的百分比。
| 解决方案名称 | 在组合中所占的百分比 |
|---|---|
文档上载（包括编辑文档属性） |
20 |
文档下载 |
20 |
访问文档库 |
20 |
访问包含内容查询 Web 部件的主页 |
10 |
托管元数据回退查询（5,000 个以上的结果） |
5 |
托管元数据选择性查询（100 个结果） |
10 |
内容类型回退查询（5,000 个以上的结果） |
5 |
内容类型选择性查询（100 个结果） |
10 |
限制
限制可阻止对服务器场性能产生负面影响的操作。已测试这些默认值并仔细进行了选择。对于某些限制（如列表视图阈值），强烈建议您不要更改该值。仔细考虑更改这些限制所产生的影响。如果这些限制会阻止某个操作的执行，则应先考虑将该操作更改为通过更高效的索引方式运行，而不是更改限制以适应性能较低的操作。可以在管理中心内配置本节中提及的大部分限制，方式是转到“管理 Web 应用程序”，然后选择特定 Web 应用程序的功能区中的“常规设置 – 资源限制”。
列表视图阈值
SharePoint Server 2010 支持包含数千万个项目的文档库和列表。可以使用文件夹、标准视图、网站层次结构和元数据导航创建超大型文档库。若要使用列表视图或协作应用程序标记语言 (CAML) 检索大型列表中的数据，则必须使用文件夹和/或索引对数据进行分区。否则，搜索会是可用于高效访问数据的唯一机制。单个文档库可支持的项目数是可变的，具体取决于文档和文件夹的组织方式、已存储文档的大小和类型、文档库的使用率以及文档库中的列数。
提示
在引入列表视图阈值后，您可能希望了解该阈值与 Office SharePoint Server 2007 中有关每文件夹 2,000 个项目的建议存在何种关联。似乎新的限制为 5,000 而不是 2,000。如果用户主要是使用文件夹浏览内容，则概念相同。但是，在引入元数据导航重试和回退后，大型查询将返回一小部分结果以获得更佳性能。这意味着，文件夹中可包含数千个项目，并将在查询返回过多结果时保护性能。
默认情况下，列表视图阈值会阻止涉及 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=0x804)。
下图显示了针对大型列表的查询组合在调整列表视图阈值时的吞吐量。此查询组合包含返回列表中所有项目的查询，随着列表视图阈值的增大，返回的项目会更多。即使将限制从默认值 5,000 更改为 10,000，也会对性能产生重大影响。建议您不要更改默认列表视图阈值并将重心转向确保查询正常运行上，而不是通过增大或减小列表视图阈值来改进性能。
.gif "显示列表视图阈值吞吐量的图表")
列表视图阈值异常因低性能操作导致发生。应重新配置操作。您应考虑操作的执行效率较低的原因并修复这些操作，而不是提高限制。在最差的方案中，您可以暂时将特定列表的 EnableThrottling 设置更改为 false 以忽略列表视图阈值。只能在列表级别而不是对网站执行此操作。应执行此操作以仅允许列表访问，直到可进行相应的更改以修复列表视图阈值所阻止的低性能操作。应尽快将 EnableThrottling 设置更改回 true。
重要
列表视图阈值异常很常见，尤其会在升级后立即出现。似乎通过更改列表视图阈值来解决这些问题会更轻松。强烈建议您不要更改列表视图阈值。
列表视图阈值不会阻止查询源自的前端 Web 服务器上的服务器场管理员和本地计算机管理员。这些用户在浏览未正确配置的大型列表是应小心，并且必须小心执行测试。可能看上去一切按预期运行，但返回给用户的数据可能大不相同。有关列表视图阈值阻止的操作的列表，请参阅下文的列表视图阈值阻止的操作。
类似地，可使用未受列表视图阈值保护的帐户运行定时服务。虽然这会导致出现某些情况（如在大型列表中创建索引时出现延迟），通常您应特别小心以确保代码避免执行大型列表操作。
列表视图阈值
默认值：5,000 |
在 2007 中是否存在：否 |
可配置：是 |
配置位置：管理中心，针对每个 Web 应用程序 |
面向审核员和管理员的列表视图阈值
默认值：20,000 |
在 2007 中是否存在：否 |
可配置：是 |
配置位置：管理中心，针对每个 Web 应用程序 |
面向审核员和管理员的列表视图阈值是用于特定服务帐户（如搜索查询帐户或对象缓存超级读者和超级作者帐户）的列表视图阈值。例如，内容查询 Web 部件会自动使用此限制以缓存大型查询的结果，从而节省服务器资源。如果根据 Web 应用程序安全策略以作为超级读者或超级作者的帐户运行，则可使用自定义代码请求对此更高限制的使用。
允许对象模型覆盖
默认值：是 |
在 2007 中是否存在：否 |
可配置：是 |
配置位置：管理中心，针对每个 Web 应用程序 |
允许对象模型覆盖指定服务帐户是否能使用面向审核员和管理员的列表视图阈值。服务器场管理员必须启用对象模型覆盖并以编程方式指定列表为一个异常。然后，具有适当权限的程序员可以编程方式请求其查询或列表使用更大的列表视图阈值以便审核员和管理员使用该阈值。通过将值更改为“否”，审核员或管理员运行的自定义代码（即使它请求覆盖）也将受列表视图阈值的约束，而不是受面向审核员和管理员的更高限制的约束。建议您将此设置保持为默认值，并仅配置面向审核员和管理员的列表视图阈值（如有必要）。
每日时间范围
默认值：关闭 |
在 2007 中是否存在：否 |
可配置：是 |
配置位置：管理中心，针对每个 Web 应用程序 |
可以设置每日时间范围，以便在不受列表视图阈值约束的情况下执行操作。可以 15 分钟为增量调整该时间，最大为 24 个小时。在每日时间范围内开始的数据库操作或查询会继续执行直至完成（即使未在指定时间范围内完成）。默认情况下未配置每日时间范围，因为各个部署之间的非高峰时段大不相同。因此，这将留待管理员来决定。建议您在以下情况下指定每日时间范围：少数用户在合理的非工作时间段内使用 Web 应用程序。这将允许用户在服务器场使用率很低的时段内对大型列表执行管理性操作（如创建索引）。
唯一权限
当列表中的唯一权限数增大时，性能会降低。您应重新考虑必须对大型列表中的所有或大部分内容实施唯一保护的任何设计。针对具有 0 个和 1,000 个唯一权限的列表的操作的吞吐量之差约为 20%。每个列表的可配置默认值为 50,000 个唯一权限。不过，建议您考虑将此限制降低为 5,000 个唯一权限，并考虑对大型列表应用使用尽可能少的唯一权限的设计。这将帮助提高性能和可管理性。
有以下建议：
最大程度地避免对单个项目使用唯一权限，并简化要求大多数项目具有唯一权限的列表设计。
如果需要唯一权限，则尝试仅在列表或文件夹级别设置唯一权限，并最大程度地减少需要唯一权限的项目数。
如果每个项目均需要单独权限，则重新考虑您的设计。调查多个列表间分开的项目或将项目组织到文件夹和组中，以便能授予适当的访问权，而无需为每个项目设置唯一权限。
设置细化权限会影响性能，如果对多个不同的项目分别设置细化权限，则难于管理该权限。对超过列表视图阈值的列表或文件夹设置细化权限将被阻止，因为必须更新的单个项目过多。但是，设置细化权限也会通过其他方式影响性能。因此，有一个可配置的限制，其默认值为每列表 50,000 个唯一权限。当您尝试在达到此限制后声明唯一权限时，将会被阻止。与列表视图阈值不同，此限制在您对项目创建唯一权限时（而非查询时）适用。
只要中断对某个项目（如文件夹）的权限继承，就会将其计为一个此限制值限定的唯一权限。每当中断权限继承时，都会创建一个新的范围 ID。每次对视图执行查询时，都会针对范围表进行联接。之后，在执行查询时，必须分析和处理每个唯一访问控制列表 (ACL)。列表中的大量唯一权限将对性能产生负面影响，建议不要使用这些权限。随着列表中唯一权限的数目的增多，查询性能将下降。即使默认限制为 50,000 个唯一权限，您也可能需要考虑将此限制降低为 5,000 个唯一权限。
唯一权限
默认值：50,000 |
在 2007 中是否存在：否 |
可配置：是 |
配置位置：管理中心，针对每个 Web 应用程序 |
换行
在向列表中添加列时，这些列会映射到 SQL Server 数据库表中的列。对于各个不同的列类型，数据库表中的每个行均支持固定数量的列。例如，一个数据库表行支持 8 个日期和时间列以及 12 个数字列。如果有 8 个以上的日期和时间列，则每个列表项将使用两个数据库表行。
对于小型列表，可以忽略换行对性能产生的影响。但是，对于大型列表，换行会产生重大影响。在换行之前可以有任意数量的列达到限制，但只要有一个列类型超过了限制，则会进行换行。
下表显示了换行前达到的特定数据类型的列数。
| 列类型 | 每个表行对应的列数 |
|---|---|
单行文本 或 选项和多行文本 |
64 32 |
日期和时间 |
8 |
是或否 |
16 |
数字和货币 |
12 |
已计算 |
8 |
整型、单值查找、人员和组、托管元数据 |
16 |
唯一标识符 |
1 |
对于大多数操作，换行会导致每个额外行的吞吐量降低约 35%。若要检查列使用的行数，您必须分析列表架构并查看列表中的字段的列类型。
下图显示了在用于列表的 SQL Server 数据库行的数目增加以容纳更多托管元数据列时的只读查询性能。为了换到第二行，向列表中添加了 15 个托管元数据列；为了换到第三行，向列表中添加了 31 个托管元数据列。仅使用对列表项进行筛选的查询执行了测试。每个额外的行的吞吐量降低约 35%。
.gif "显示换行吞吐量的图表")
行大小限制
默认值：6 |
在 2007 中是否存在：否 |
可配置：是 |
配置位置：仅对象模型，SPWebApplication.MaxListItemRowStorage |
行大小限制指定了数据库中用于每个列表项的表行的最大数目。为了适应包含多个列的大型列表，每个项目会跨越多个内部表行（最多 6 行）。例如，如果有一个包含多个小型列的列表（一个包含数百个“是/否”列的列表），则可能会达到此限制。在此情况下，将无法向列表添加更多的“是/否”列。但是，也许能够添加其他类型的列。每个额外的行均增加了开销，因此对于大型列表，应最大程度地减少相同类型的列的数目以避免换行。
查找列和列表视图
列表视图中的每个查找列都会导致与另一个表联接。视图中的每个额外的查找列会增大元数据导航和列表视图查询的复杂性。除标准查找列之外，单值托管元数据、多值托管元数据，单值人员和组列以及多值人员和组列都会计为查找列。向视图添加查找列并不会导致性能逐渐或线性降低，性能而是会保持相对稳定，直到添加 8 个列之后，性能才会快速下降。
下图显示了当视图中查找列的数目增加时发生的吞吐量更改。显而易见，性能变化在添加 0 个到 8 个列之间相对稳定，而在添加 10 个查找列后，吞吐量会大幅度降低。通过仅使用一个行对列表执行了此测试。如果列表发生换行，性能下降得更快。
.gif "显示视图吞吐量中的查找列的图表")
下图显示了当视图中的查找列的数目减少时的 SQL Server CPU 利用率。显而易见，在添加 10 个查找列时发生了显著变化。对于具有大量查询的列表，包含带有 8 个以上的查找列的视图会导致查询使用与其不成比例的大量 SQL Server 资源。建议您不要将此限制更改为大于 8。
.gif "显示 SQL CPU 使用率的图表 - 查找列")
此性能降低针对的不是列表上查找列的总数，而是仅针对视图或查询中查找列的数目，但 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 个项目（超过列表视图阈值），则无法删除该文件夹，因为操作超过了列表视图阈值。
当列表超过列表视图阈值时，您必须规划正确配置视图和其他导航选项。理想情况下，您应预先配置视图和其他导航选项，但通常列表会增大并超过列表视图阈值，此时需要采取措施。某些操作（例如，在包含许多项目的列表中创建一个列或为一个列编制索引）会花费很长时间。列表视图阈值将阻止这些操作。但是，可以在每日时间范围内这些操作，也可以由服务器场管理员或计算机管理员执行这些操作。您应先规划这些操作，然后再执行它们。如果列表已过大，则规划每日时间范围或管理凭据来执行这些操作。
提示
在设置列表时，列表视图阈值会阻止某些常见的管理性操作。如有可能，您应在列表大小超过列表视图阈值之前配置列的所有内容类型、列和索引。
列表可变得非常大，从而导致在使用 Web 浏览器运行某些操作时可能发生超时。例如，如果列表包含数百万个文档，则添加新列可能会花费较长时间。若要完成此操作，您将需要使用 Windows PowerShell 并确保在非高峰时段执行此操作，因为它将阻止其他用户的操作。
列表视图阈值所阻止的操作
下表列出了列表视图阈值所阻止的操作。
列表超过列表视图阈值时阻止的操作
| 操作 | 说明 |
|---|---|
添加/删除/更新列表列 |
所有列（包括查找列和计算列）以及多种更新（如类型更改或唯一性更改）。不会阻止某些更新（如名称更改），因为它们不会影响列表中的每个项目。 |
添加/删除/更新列表内容类型 |
将影响列表中的每一项，因此，对于任何项数超过列表视图阈值的列表，此操作将被阻止。 |
创建/删除索引 |
将影响列表中的每一项，因此，对于任何项数超过列表视图阈值的列表，此操作将被阻止。 |
管理不具有签入版本的文件 |
一个非索引递归查询，无法对包含的项目数超过列表视图阈值的任何列表执行此查询。 |
非索引递归查询 |
将包括筛选和某些排序。当列表大小超过列表视图阈值时，此操作将失败。由于没有任何索引，该操作会对整个列表执行全面扫描。此外，该操作会返回所有项目并忽略文件夹。 |
跨列表查询 |
将包含由内容查询 Web 部件执行的查询，并遵循面向审核员和管理员的列表视图阈值设置，其默认值为 20,000 个项目。如果该操作涉及 20,000 个以上的项目，则查询将失败。 |
强制实施关系行为的查找列 |
当引用列表包含的项目数超过列表视图阈值时，无法创建强制实施关系行为的查找列。 |
删除列表 |
将影响列表中的每一项，因此，对于任何项数超过列表视图阈值的列表，此操作将被阻止。 |
删除网站 |
如果某个网站中的项目总数超过列表视图阈值，则阻止删除该网站，因为此操作会影响过多项目。 |
将列表保存为带数据的模板 |
将影响列表中的每一项，因此，对于任何项数超过列表视图阈值的列表，此操作将被阻止。 |
在列表视图中显示总数 |
将对列表中的每个项目执行查询，因此，对于任何项数超过列表视图阈值的列表，此操作将被阻止。 |
在列表中启用/禁用附件 |
将影响列表中的每一项，因此，对于任何项数超过列表视图阈值的列表，此操作将被阻止。 |
当容器超过列表视图阈值时阻止的操作
| 操作 | 说明 |
|---|---|
删除/复制/重命名文件夹 |
此操作在文件夹包含的项数超过列表视图阈值时失败，因为它会影响过多的行。 |
对非索引列执行筛选的查询 |
此操作在容器（文件夹或列表）包含的项数超过列表视图阈值时失败。由于没有任何索引，该操作会对整个文件夹执行全面扫描。 |
设置细化安全权限 |
此操作在您尝试设置细化权限的列表或文件夹包含的项数超过列表视图阈值时失败，因为它会影响过多的列。您仍可对大型列表中的子项目（如文档）设置细化权限，尽管无法对列表本身或包含的项数超过列表视图阈值的文件夹设置这些权限。 |
使用资源管理器打开 |
如果容器包含的项数超过列表视图阈值（子文件夹中的项目除外），则不显示任何项目。如果一个文件夹包含 8,000 个项目，但它有一个子文件夹包含了 4,000 个项目，根中仅有 4,000 个项目，则“使用资源管理器打开”操作将正常工作。如果列表的根包含的项数超过列表视图阈值，则“使用资源管理器打开”操作将不显示任何内容。若要使用“使用资源管理器打开”操作，则列表必须已将少于列表视图阈值的项目组织到任何容器的根的文件夹中。 |
无法按预期方式工作的可用功能
本节包含有关无法在大型列表中按预期方式工作的功能的信息。
数据表视图
如果列表增大并超过列表视图阈值，则文档库的库功能区选项卡中可用的数据表视图按钮不会被禁用。但是，如果列表大小超过列表视图阈值，则该视图会加载一些项目，并会显示一条消息：“您无权查看整个列表，因为该列表超过管理员强制实施的列表视图阈值。”可以从列表的设置中的功能区禁用数据表视图选项。此外，还有一个 50,000 个项目的硬性限制，因此，即使列表视图阈值在 50,000 个项目以上，该视图仍会被阻止。
规划大型列表设计和实施
在实施大型列表之前，请考虑业务案例和要求。诸如服务级别协议 (SLA)、备份和还原所需的时间、内容大小、内容量（项目数）以及访问时间等要求都是要考虑的重要因素。根据应用程序的大小和需求，您必须在多个层面（包括硬件、内容存储和 SharePoint Server 2010 信息体系结构）做出重大决定。包含数百万个项目和数百个并发用户的大型应用程序可能需要针对特定项目的独立硬件，尽管具有数十个并发用户和数万个文档的文档存储库可以与现有网站中的现有共享硬件和单个文档库很好地协作。
规划的最终结果应为列类型（名称、数据类型和使用率）、索引、文件夹结构、用于导航的页和链接的使用率、规划的权限结构、估计项数和总体数据大小的列表。详细信息还应包括有关将执行的查询类型的信息以及有关如何访问、创建和更新列表中的数据的信息。
规划大型列表的设计和实现后，下一步是设计和构建原型。此规划阶段涉及设计大型列表、实现概念证明并验证其是否正常工作。在此阶段，在测试环境中填入大量内容以验证有关数据访问和性能的假设可能会很有用。设计过程所获得的最终结果应为预期列表的概念证明、列的文档、内容类型、文件夹结构、视图、索引、用于元数据导航或其他检索方法的列、使用的任何分类、各种 Web 部件的用法及其他功能（如内容管理器）的用法。
估计内容大小
对于大型列表，估计各种数目以做出容量规划和设计决策非常重要。需要规划几个重要数目，其中包括：
总体内容数据库大小
平均文件大小和最大文件大小
版本数
内容量 - 列表中的项目总数
内容数据库大小
总体内容数据库大小对于规划所需磁盘空间和硬件以及了解备份、还原和服务级别协议可支持的内容很重要。总体内容数据库大小对于了解备份和还原所需的停机时间量最为重要。
可通过将平均文档大小乘以每个文档的平均版本数再乘以预期文档数所得的结果来估计内容数据库大小。除了添加文件之外，还应向内容数据库数据中添加额外的 20% 的数据。此数目很大，因为版本数通常会随时间而增大，因此，签入文档的平均文件大小通常会大于所有版本的平均文件大小。您应添加一个较大的缓冲区，以防列表超过预期大小，除非您拥有可有效控制内容量的机制。
平均文件大小和最大文件大小
需要最大文件大小以确保为可上载的文件指定正确的 Web 应用程序设置（默认值为 50 MB，最大值为 2 GB）。平均文件大小用来帮助了解内容的增长速率并估计总体内容大小。可通过计算当前充当预期系统的系统中的文件数来估计平均文件大小。
提示
您应规划将向内容数据库添加额外的 10% 到 20% 的数据并添加文件，并且搜索索引约占内容数据库大小的 75%。
平均版本数
您必须考虑版本控制，因为它会显著增大内容大小。有一些可用来限制版本数的方法。例如，可以使用信息管理保留策略来在特定时段后删除所有早期版本，也可以限制要保存的版本数。其他因素也会影响版本数，例如，如果使用内容管理器将所有内容提交到存储库，则可能不会有任何版本，因为内容管理器只复制最新签入的版本。如果用户主动编辑存储库中的文档，则您可能需要考虑共同创作；每个共同创作会话将自动创建一个版本。请考虑存储库的使用率，并计算现有解决方案数以估计将为文档创建的版本的平均数。
内容量
内容量是指单个列表中的项目总数。若要估计内容量，您应计算现有内容源和将移动到新系统的内容，或检查将使用该系统的用户数以及该系统的用途。有其他一些相关的数目，包括每个容器的项目数和每个元数据透视或索引筛选器的项目数。当您规划视图和元数据导航时，这些数目也很重要。
远程 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 数据范围。无需仅使用远程 BLOB 存储，因为您的内容数据库大小是以 TB 计的。您将需要彻底了解备份和还原以及服务级别协议。远程 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 自动保留：ID、内容类型、修改时间、创建时间、修改者、创建者、文档 ID
由自定义项保留的列：
按“产品类型”和“产品工作组”文件夹分类的元数据默认值（每个产品类型具有一个文件夹，每个“产品类型”文件夹具有多个“产品工作组”文件夹）
工作流更新：审批状态、已完成项目
由用户保留的列：设计人员、测试人员、最终评审日期
适用于导航的列：内容类型、产品类型、产品工作组
用来跟踪状态且适用于导航的列：最终评审日期、审批状态、已完成项目
对导航有用的列：设计人员、测试人员、产品名、修改时间、修改者
列建议摘要
最大程度地减少可填写的列的数目。
仔细选择将用于系统进程和导航的列。考虑哪些字段是必需的，并最大程度地减少必需字段的数目。
应在导航需要必需字段时使用这些字段（例如，对特定字段使用内容查询 Web 部件）。还应将必需字段用于管理（例如，对用户必须指定的日期字段指定保留操作）。
由于对单值列进行查询的速度快于对多值列进行查询的速度，因此请尝试将列设置为单值（除非需要多值）。
列表中特定列的总数会导致换行，从而降低性能。最大程度地减少大型列表中的列数并避免换行（如有可能）。
文件夹
应仔细考虑如何将内容组织到文件夹中。文件夹具有以下三类用途：
以逻辑方式将内容组织到文件夹中。例如，基于签订合同的年份或月份将合同组织到文件夹中，或基于开具发票的日期将发票组织到文件夹中。在此方案中，用户可轻松浏览文件夹结构或使用元数据查找文档。另外，文档可轻松自动传送到正确的文件夹。内容管理器提供了一些功能，当添加的项目数超过特定限制时，可使用这些功能通过创建子文件夹来限制单个文件夹中的项目数。
将内容组织到文件夹中以实施保留和权限或其他管理功能。例如，包含极少用户可访问的机密文档的文件夹或基于位置的保留，这样一来，文档便具有基于其文件夹的不同保留计划。在此方案中，用户导航可能更为困难，因为只要用户可以访问某个文档，就不会关注该文档的位置。元数据导航和搜索是用于查找文档的主要方法，而不是使用文件夹结构查找文档。
将内容组织到文件夹中以帮助用户按主题或类别进行导航。许多用户习惯于使用文件夹进行导航。对于特定应用程序，保留文件夹结构可能很重要，因为这可使用户能够轻松导航。在此方案中，用户通常了解文件夹结构并知道在何处查找和放置文档。元数据导航和搜索可与此方法结合使用。
利用 SharePoint Server 2010 中的功能改进，可以更灵活地使用文件夹，并更少地依赖性能注意事项。通过使用托管元数据和元数据导航，用户可轻松对元数据进行筛选，而不是通过文件夹导航。这使您能够出于管理目的组织内容（如权限或策略），而不是仅为用户导航组织内容。例如，您可以创建两个文件夹，一个文件夹包含仅特定员工可以访问的已分类材料，另一个文件夹可供所有员工访问。可以对文件夹指定不同的权限，然后使用内容管理器基于元数据将内容自动移动到相应的文件夹。仍可以选择将文件夹导航与元数据导航一起使用。
使用内容管理器功能，内容可基于内容类型和元数据自动移动到文件夹中，而无需用户确定内容的放置位置。另外，当一个文件夹已达到指定项目限制时，可使用内容管理器自动创建新文件夹。如果未将项目组织到文件夹（这些文件夹中的项目数未超过任何文件夹的根中的列表视图阈值）中，则必须考虑使用“使用资源管理器打开”(WebDAV) 将不适用于大型列表。
基于文件夹的视图和基于元数据的视图在性能上很相似。从逻辑和用户体验的角度来看，使用文件夹划分内容是明智的。元数据导航会执行递归查询，以便所有项目在文件夹外部返回。如果这是检索内容的主要方法，则文件夹结构可能会变得不重要。
下图显示了通过使用不同类型的视图访问相同数目的项目来执行测试所获得的结果。所有视图返回了 1,000 个结果。此图显示了各个视图在列表增大时每秒发出的请求数。结果表明，随着列表的增大，文件夹和索引视图的性能保持相对稳定，只不过列表越小，文件夹的性能越高。对于大多数大型列表，会将文件夹和索引视图结合使用，这样一来，性能差异将不指示是使用文件夹还是索引检索数据。
.gif "显示文件夹和索引视图吞吐量的图表")
文件夹建议摘要
规划如何将项目组织到文件夹中。可自动或手动移动项目。
诸如元数据导航之类的功能降低了限制文件夹中的项目数的必要性。
将元数据导航与文件夹导航结合使用。因此，文件夹可用来管理策略和保留，而不是仅用来组织内容以供检索。
在提供最佳用户体验时，请考虑将内容组织到文件夹中以帮助导航，甚至将其与其他导航选项一起使用。
在使用内容管理器基于元数据将文档自动移动到文件夹中时，请考虑启用此选项以便在达到特定限制时在子文件中创建额外的项目。
如果您计划使用“使用资源管理器打开”(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 和信息管理策略保留）保留索引槽。
在使用单个字段利用内容查询 Web 部件（即，带有筛选器的视图）进行筛选时，以及在使用元数据导航层次结构和通常用作单个筛选器的多个筛选器时，创建单一索引。
为使用两个列进行筛选并且通常返回的项目数会超过列表视图阈值的查询（但这些查询可以一起选择）创建复合索引。
索引会对某些操作（如添加文档或编辑文档属性）的性能产生负面影响。因此，仅在必要时创建索引。
仔细规划索引
列表具有 20 个索引的硬性限制，并且索引列对大型列表非常重要。因此，您必须仔细选择单一索引和复合索引。有多项功能使用了索引。例如，元数据导航功能会自动为配置的导航层次结构和主要筛选器编制索引。您应对在导航和信息体系结构中进行筛选很重要的列创建索引。
自动创建的索引
SharePoint Server 功能可创建针对列表索引限制进行计数的索引。下表提供了 SharePoint Server 2010 功能的列表，这些功能在添加索引列的文档库中很常见。
| 列 | 功能 | 用法 |
|---|---|---|
保留和记录状态 |
现场记录管理或保留与 eDiscovery |
在启用“现场记录管理”网站集功能或“保留与 eDiscovery”功能，并在列表中将一个项目声明为记录或置于保留状态时，添加此列并为其编制索引。 |
到期日期，内容类型 |
信息管理策略 |
在为添加到列表中的内容类型的“信息管理策略”启用“保留”，或在列表中启用基于位置的保留时，添加这两个列并为其编制索引。 |
何时创建单一索引和复合索引
元数据导航功能会自动为在元数据导航设置页上选择的层次结构和主要筛选器列创建适当的索引。为所有层次结构树字段和一些选择性更高的主要筛选器类型创建单一索引，以便在单独使用它们时可返回索引结果和部分结果。为所有受支持的层次结构和主要筛选器的组合创建复合索引，以便在同时使用树筛选器和主要筛选器值时最大程度地提高选择性。
对于包含可能需要筛选的多个列的列表，您可能需要手动管理索引以避免达到索引限制。如果绝不会使用导航层次结构和主要筛选器的特定组合，则不考虑创建复合索引以减少索引数目。在创建这些索引时，选择为具有选择性且可在列表视图中单独使用的列（在选择另一个列之前，作为唯一筛选器或作为应用的第一个筛选器）创建单一索引很重要。当在元数据导航或自定义查询中经常将这两个筛选器一起使用时，以及当一个索引本身不具有选择性时，应使用复合索引。为用于筛选列表视图、Web 部件和其他数据访问方法的列创建索引。
在一些情况下，多个索引可能不起作用。考虑以下情况，您对“部门”和“内容类型”这两个列进行筛选。由于这是一个 AND 操作，因此仅返回同时符合“部门”和“内容类型”筛选条件的交集。这意味着，当执行查询时，先返回符合“部门”筛选条件的所有项目，然后按“内容类型”筛选这些项目。如果只有 10 个项目与特定部门匹配，则您将有一组足够少的数据，以至于内容类型的索引无关紧要。如果有数千个项目与“部门”值匹配，则应使用复合索引。
复合索引允许您对两个列创建一个索引，以便能进行更有效的查询。在对两个列执行 AND 操作时，应使用复合索引。元数据导航是唯一使用复合索引的现有 SharePoint Server 功能。启用元数据导航功能后，将使用重试和回退逻辑，即使未为列表配置元数据导航控件也是如此。视图不会使用复合索引，除非它是元数据导航查询。
索引性能影响
对包含的项目数超过单一容器中的列表视图阈值的列表执行查询需要使用索引，索引可实现显著的性能改进。虽然索引是对大型列表执行高效查询所必需的且能大大提高查询性能，但索引会对其他操作产生负面影响，因为必须保留索引。在创建、更新和删除项目时，还必须更新该项目涉及的所有索引。通过在包含 10,000 个项目的列表中进行上载、更新和删除操作执行了测试，获得的结果表明，数目介于 0 到 20 个之间的索引产生的影响低于 10%。
索引创建
默认情况下，元数据导航功能会自动创建单一索引和复合索引。可从元数据导航设置页中禁用此选项。元数据导航功能会自动为每个受支持的列类型创建单一索引，并为每个受支持的导航层次结构与主要筛选器的组合创建复合索引。不会自动为两个主要筛选器的组合创建复合索引，不过您可手动执行此操作。元数据导航会自动为支持索引的大多数列类型创建单一索引和复合索引。不会自动为具有较少的值且无法单独选择的主要筛选器类型创建单一索引。这包括“是/否”、单一值选项或内容类型列，但支持索引并可手动创建索引。
受支持的单一索引列
下表提供了有关元数据导航自动创建的索引的信息。元数据导航会为支持创建索引的所有列创建单一值索引。
| 列类型 | 是否创建索引 |
|---|---|
导航层次结构 |
|
单一值托管元数据 |
是 |
多值托管元数据 |
否（系统编制多值索引） |
内容类型 ID |
是 |
单一值选项 |
是 |
文件夹 |
否（按文件夹为系统编制索引） |
主要筛选器 |
|
单一值托管元数据 |
是 |
多值托管元数据 |
否（系统编制多值索引） |
内容类型 ID |
否（可手动创建） |
单一值选项 |
否（可手动创建） |
多值选项 |
否（不支持编制索引） |
数字 |
是 |
日期 |
是 |
是/否 |
否（可手动创建） |
货币 |
是 |
用户（单一值） |
是 |
用户（多值）* |
否（系统编制多值索引） |
所有标记 |
否（系统编制多值索引。对项目中所有托管元数据值进行特定筛选） |
自动创建的复合索引
使用元数据导航功能，用户可同时选择导航层次结构和主要筛选器。元数据导航功能会自动为所有支持的导航层次结构与主要筛选器的组合创建复合索引。下表显示了受支持的组合。
| 导航层次结构 | 单一值托管元数据 | 多值托管元数据 | 内容类型 ID | 单一选项 | 文件夹 |
|---|---|---|---|---|---|
主要筛选器 |
|||||
单一值托管元数据 |
是 |
否 |
是 |
否 |
否 |
多值托管元数据 |
否 |
否 |
否 |
否 |
否 |
内容类型 ID |
是 |
否 |
否 |
否 |
否 |
单一值选项 |
否 |
否 |
否 |
否 |
否 |
多值选项 |
否 |
否 |
否 |
否 |
否 |
数字 |
是 |
否 |
是 |
否 |
否 |
日期 |
是 |
否 |
是 |
否 |
否 |
用户（单一） |
是 |
否 |
是 |
否 |
否 |
所有标记 |
否 |
否 |
否 |
否 |
否 |
是/否 |
是 |
否 |
是 |
否 |
否 |
货币 |
是 |
否 |
是 |
否 |
否 |
用户（多值） |
否 |
否 |
否 |
否 |
否 |
元数据选择性
当列表增大时，元数据选择性的重要性会随之提高。以下建议仍适用于任何列表大小。但对于更小的列表，这些建议可能并不那么重要。
选择性是在返回查询的结果时必须考虑的项目数。它包含两个方面：实际选择性（与查询的搜索条件匹配的结果的总数）和限制选择性（对索引列应用适当条件后必须考虑的结果的总数）。实际选择性是考虑用户体验时的主要注意事项。限制选择性是考虑对 SQL Server 实例产生的影响时的主要注意事项。
若要有效使用元数据导航和其他列表筛选机制，用于筛选的元数据必须具有选择性。默认情况下，列表视图会显示 30 个项目以便用户能快速扫描结果来查找所需内容。如果查询返回 30 个以上的结果，则用户必须使用分页来查找结果。如果使用的是内容查询 Web 部件，则获得的结果数一般介于 10 到 15 之间。如果结果数超过此数目，则不会显示多出的其他结果。如果通过一个查询获得数百个结果，则很难找到所需内容。此外，选择性对于帮助阻止超过列表视图阈值的操作也很重要，在元数据导航中，这些操作会导致回退且不会返回所有结果。
内容管理器和自动平衡
内容管理器可以是用于在文档库中组织内容的中央组件。在使用内容管理器的存储库提供的提交体验中，用户在文档处于最终状态时才将文档上载到存储库中。可使用内容管理器的一些示例方案包括：
基于各网站中和各网站之间的元数据自动传送文档。
自动传送文档并创建新的文件夹，如基于天、月份和年份的文件夹。
自动平衡文件夹中的项目数量。
数据访问和检索
大多数大型列表的主要用途是存储内容以供检索。规划用户检索内容的方式很重要，因为检索方式对大型列表的性能以及成功实现大型列表会产生最大影响。搜索、元数据导航、内容查询 Web 部件和视图这几项功能都可用于帮助用户检索内容。通常还会使用自定义解决方案（如针对数据进行查询的自定义 Web 部件）。预先规划网站的组织方式。可以使用中央登录页（如文档中心网站的主页）汇总内容并提供大型列表的入口点。还可使用发布页创建一个其每个页面均涵盖了各种主题的网站，然后使用 Web 部件从大型列表中提取相关文档或项目。针对数据访问和检索的注意事项包括：
可使用搜索、内容查询 Web 部件、元数据导航、列表视图和自定义 Web 部件的任何组合。
预先规划内容的检索方式以及将用于筛选和排序的列。
规划基本页面模型。考虑是否在文档库中执行所有工作或是否存在登录页或链接到相关内容的多页模型。
数据访问方法
SharePoint Server 2010 的以下三种主要功能可用于查询和筛选具有简单配置的列表数据：列表视图和元数据导航、内容查询 Web 部件和搜索。还提供了使用自定义代码查询列表的额外选项；本文不对这些选项进行说明。
视图允许您配置所显示的列。有多种用于显示列表数据的方法。可将视图配置为基于列筛选和排序结果。
- 元数据导航是 SharePoint Server 2010 列表视图的一个筛选控件。在配置元数据导航时，可以选择元数据层次结构和主要筛选器来动态筛选列表视图中显示的结果。
内容查询 Web 部件显示 SharePoint Server 2010 列表中的数据。可将查询配置为返回一个或多个列表中的结果。默认情况下，将缓存内容查询 Web 部件。但是，可以不对该部件进行缓存。
搜索框或搜索结果 Web 部件可用于返回搜索结果。可将这些结果的范围缩小到一个特定列表，然后使用搜索元数据精简控件执行引导式搜索。
下表列出了查询方法及其使用方式。
| 查询方法 | 用法 |
|---|---|
列表视图和元数据导航 |
列表视图始终访问 SQL Server 后端数据库，这会生成对性能影响最大的查询并导致 SQL Server 负载更重。使用列表视图可提供用于与文档交互（签入、签出和编辑属性）更多的选项以及对数据的实时访问权。 |
内容查询 Web 部件 |
内容查询 Web 部件使用门户网站地图提供程序来缓存查询，它们呈现的 HTML 最少，因此查询的速度最快且呈现时间最短。使用内容查询 Web 部件进行动态导航并对单个页面执行多次查询。 |
未缓存的内容查询 Web 部件 |
为了提供对数据的实时访问，内容查询 Web 部件可直接查询数据库。在无法缓存查询时和需要实时更新时使用此配置，并对每小时访问低于一次的页面使用此配置以便绝不会填充缓存。初始加载缓存的内容查询 Web 部件会产生额外的开销。 |
搜索 |
使用搜索查询可将读取操作卸载到更易于缩放且已针对读取性能进行优化的服务器基础结构。可将搜索查询配置为使用静态查询，也可以允许用户指定搜索查询。 |
内容查询 Web 部件
下表显示了使用内容查询 Web 部件的各种优缺点。
| 优点 | 缺点 |
|---|---|
|
|
内容查询 Web 部件用于检索列表中的内容。可将该部件用于页面、文档和列表项。默认情况下，将缓存内容查询 Web 部件，从而提供更佳的性能并减小对 SQL Server 资源产生的影响。默认缓存设置为 30 分钟。因此，数据将保持最新。但这也意味着，内容查询 Web 部件使用的 SQL Server 资源会多于搜索查询使用的资源。由于内容查询 Web 部件呈现的 HTML 最少，因此呈现页面的速度更快，并且可在一个页面上配置多个内容查询 Web 部件。当列表增大时，缓存的内容查询 Web 部件会提供快速数据访问。未缓存的内容查询 Web 部件具有的延迟几乎与类似的列表视图查询相同。
应将内容查询 Web 部件用作导航组件，以便提供页面内容汇总。例如，可使用页面提供对文档库中包含的内容的概述，然后使用内容查询 Web 部件返回相关页面和文档。其他一些示例包括当前用户修改的项目、最新项目以及评级最高的项目。内容查询 Web 部件可在读取操作较多的方案中使用，在此类方案中，大多数用户无需执行签入、签出或管理版本等列表操作。下图是一个内容查询 Web 部件，该部件显示了评级最高的文档。
.gif "最高级别文档的屏幕截图")
可使用内容查询 Web 部件访问内容，而无需进入列表视图。用户可能会频繁访问少量内容或需要跟踪一些项目。在“文档中心”网站模板中，默认情况下会使用三个内容查询 Web 部件：一个部件可返回已登录用户所修改的项目，另一个部件适用于评级最高的文档，第三个部件适用于最新文档。将这三个内容查询 Web 部件组合在一起可提供一个登录页面，该页面提供了用户可能频繁访问的内容或用户最感兴趣的内容。这可以支持发现新内容和快速访问频繁使用的文档。又例如，创建收藏夹列表以便用户能标记内容以进行跟踪，然后使用内容查询 Web 部件返回收藏夹列表，以便用户能快速访问频繁使用的内容，而无需访问列表本身。
在对大型列表使用内容查询 Web 部件时，需要注意一些重要事项以确保它返回正确的结果，并且不会被列表视图阈值阻止。必须使用索引列来筛选项目，使其数目低于列表视图阈值。建议您不要在其中一个列表为大型列表时使用跨列表查询。如果跨列表查询中考虑的项目总数大于面向审核员和管理员的列表视图阈值（默认情况下为 20,000），则将阻止操作。
内容查询 Web 部件建议摘要
使用内容查询 Web 部件可返回用户可能频繁访问的项目、感兴趣的项目或可帮助用户发现内容的项目。
在对大型列表使用内容查询 Web 部件时，应筛选项目以便查询不会超过列表视图阈值。
应仅对索引使用列以进行筛选。
如果考虑的项目总数大于面向审核员和管理员的列表视图阈值（默认情况下为 20,000），则不要使用内容查询 Web 部件查询多个列表。
使用缓存以提高加载速度和减小 SQL Server 负载。
搜索 Web 部件
下表显示了搜索 Web 部件的各种优缺点。
| 优点 | 缺点 |
|---|---|
|
|
搜索查询的缩放性高于直接访问 SQL Server 资源的缩放性，因为已针对读取操作较多的方案优化了搜索，并且向外扩展到多个搜索索引和查询服务器比缩放 SQL Server 实例轻松得多。可使用预配置的搜索 Web 部件、搜索框或二者的组合来帮助用户检索内容。利用搜索查询，可以将查询卸载到搜索索引，从而减小 SQL Server 负载。此外，与内容查询 Web 部件或列表视图查询相比，搜索查询受列表大小的影响更小。
可以在任何方案中使用搜索来显示来自预配置的或用户指定的查询的结果。搜索可在较高的分级点中提供最佳性能。如果必须对项目执行列表操作，或者必须实时显示数据，则不应使用搜索，因为结果仅与最新爬网保持一致。下表显示了可使用的三个搜索 Web 部件。
| 搜索 Web 部件 | 说明 |
|---|---|
核心结果 Web 部件 |
采用分页的完整结果，并且是功能最全面的 Web 部件。该部件可使用系统或用户指定的查询。 |
联合结果 Web 部件 |
一小组结果，具有用于访问完整结果的可选链接。 |
搜索框 Web 部件 |
用于接受用户输入的查询内容的 Web 部件。 |
列表视图
下表显示了使用列表视图的各种优缺点。
| 优点 | 缺点 |
|---|---|
|
|
列表视图和元数据导航可支持在使用文件夹和/或索引的大型文档库中检索内容。使用列表视图进行的查询是实时执行的，并会直接查询 SQL Server 数据库。这将提供最新结果。但它对性能产生的影响也最大。对于较大的列表大小，整体吞吐量将减少且操作延迟时间将增加。列表视图还呈现了要加载的页面的大部分内容。因此，使用列表视图的页面呈现时间通常更长。
当您必须能够对项目执行列表视图操作时，应使用元数据导航和列表视图。列表视图可能是在读取操作较少的方案中使用列表的主要方法。在具有许多读取操作的方案中，您可能需要考虑将其他查询方法用作访问列表数据的主要方法。
视图配置
视图配置建议摘要
仔细选择在视图中使用的列。拥有的列越多，意味着要呈现的数据越多，这会增加页面加载时间。您需要在页面加载时间与最佳用户体验之间做出权衡。
最大程度地减少查找列的数目（如视图中的托管元数据以及人员和组），因为这将导致与其他数据库表联接并增加数据库负载。
不要对列使用汇总。
如果未使用索引列筛选视图，请选择用于显示文件夹中的项目的选项，并确保单个文件夹中包含的项目数不会超过列表视图阈值。
应基于索引列筛选视图以减少返回的项目的数目，以使该数目小于列表视图阈值（尤其是在没有子文件夹或文件夹包含的项目数超过列表视图阈值的情况下）。
启用元数据导航功能以返回查询的最新结果，否则这些结果将被列表视图阈值阻止。默认情况下，几乎所有网站上都启用了该功能。
如果您将筛选的视图与元数据导航一起使用，请考虑使用每位置视图来为元数据导航透视创建未筛选的视图以便返回所有结果。
列数和查找列数
视图是用于访问列表数据的最常见方法。应仔细选择视图以优化用户查找内容的方式并满足性能要求。对于大型列表，请特别注意视图的配置方式。仅建议标准视图和自定义视图。对于超过列表视图阈值的列表，建议不要使用数据表、甘特图和日历视图，因为它们会被列表视图阈值阻止。视图应具有尽可能少的列，但请特别注意查找列（托管元数据、人员和组以及查找类型）的数目，因为查找会对其他表执行联接，从而影响性能。
列筛选和汇总
SharePoint Server 2010 中的新列表视图阈值表示对将视图用于大型列表的方式的主要更改。如果视图尝试返回的结果的数目超过列表视图阈值，则用户将收到错误。对大型列表使用汇总将始终被列表视图阈值阻止。因此，不要使用汇总。必须扫描的项目的数目是返回的行数，它很重要但不是必需的。如果某个视图包含的筛选器的条件为“颜色”列中的值为“红色”，但“颜色”列不是索引列，则该视图可能会被阻止。即使可能只有 100 个项目匹配此查询，但如果列表中包含 10,000 个项目，则查询也必须扫描 10,000 个项目。在此情况下，用户在尝试访问视图时会收到错误。若要解决此问题，可以使用文件夹、筛选器和索引以及元数据导航。
文件夹
如果组织了列表以使任何文件夹包含的项目数都不超过列表视图阈值，则可选择用于在文件夹中显示项目的选项。应避免在文件夹外部显示所有项目，除非您可使用适当的机制筛选结果，使其数目小于列表视图阈值。
索引
在之前的示例中，对“颜色”列执行查询失败，因为未为该列编制索引。若要解决此问题，可以为“颜色”列编制索引，之后查询将正常工作（如果各个值完全不同）。如果只有 100 个红色项目，则此查询将正常工作。但是，如果匹配的项目的数目超过列表视图阈值，则即使编制了索引也会被阻止。默认情况下，会在系统中为 ID 字段、文件夹结构和多值查找编制索引。用于筛选的任何新创建的列都必须具有手动创建的索引。
示例视图
最近更改的项目
“最近更改的项目”视图用于显示最近更改的项目。当用户频繁访问最近已修改的各种源中的内容时，可将该视图用于默认视图。可轻松配置此视图，因为它会使用始终为每个项目设置的系统元数据。对于大型列表，您必须将项目限制设置为一个小于列表视图阈值的数目，或筛选结果使其数目少于列表视图阈值。若要创建此视图，您必须为已修改的字段编制索引并按降序对其进行排序。请为“修改时间”列指定筛选器并使用公式 [Today-x]，其中 x 是数据将显示的天数。选择选项（大于或等于）。公式 [Today-x] 返回的项目数应小于列表视图阈值。
我的项目
可在用户频繁访问其文档的存储库中使用“我的项目”视图。可轻松配置此视图，因为它使用的是始终为每个项目设置的系统元数据。在此视图中，按“修改者”列和/或“创建者”列进行筛选。若要在筛选器中创建此视图，请选择“修改者”列，将值设置为 [ME]，然后使用 OR 在“创建者”列（其值也设置为 [ME]）中设置第二个筛选器。当多个用户编辑相同文档时，除了使用“修改者”列之外，还应使用“创建者”列。“修改者”列不是多用户列。因此，此视图不必显示用户修改过的所有文档。在此示例中，应同时为这两个列编制索引，因为操作是 OR 操作。
结束语
SharePoint Server 2010 提供了新功能和改进后的功能，以增强使用大型列表的用户体验和性能。限制可保护其他用户的服务器场的性能，并阻止操作不成比例地使用大量 SQL Server 资源。元数据增强和元数据导航提供了检索列表数据的增强体验，并且可将内容查询 Web 部件、搜索和列表视图配置为使用大型列表。创建满足您要求的适当的解决方案仍需仔细规划。不过，可以通过配置旨在提供良好性能的现有解决方案来快速开发大型列表。