SharePoint流言终结者：一个文档库里面的文件数量不能超过2000吗？

在SharePoint平台上的众多流言中，这一定是流传得最广的流言之一：不要在一个文档库中存放超过2000个的文件（对应到列表，可以被描述成：不要在一个列表中存放超过2000个列表项）。

好吧，以下是一些供你参考的信息：

1、这里没有一个实际的硬性限制，所以用户的确可以在一个文档库中存放远远超过2000个的文件。一个拥有子文件夹的文档库（列表）可以存放500万个文件（列表项）。

2、微软提供的最佳实践是：如果在一个文件夹下存放超过2000个文件（列表项），文件夹载入的性能将随着文件数量的增加而线性下降。微软对各种使用场景进行了大量的测试，请参考白皮书《Working with Large Lists in Office SharePoint Server 2007》。

3、根据第2条，如果你使用SharePoint内置的列表视图来展现文档库（列表），在一个文件夹下面最好不要存放太多文件，但是我个人觉得这是一个很保守的数字，实际上，如果你的系统硬件不是特别差，你会发现即使在一个文件夹中存放远远超过2000个文件，也不会感到太多的性能下降。当然如果可能，最好在一个文档库中创建层级式的文件夹，然后就可以在一个文档库（列表）中存放远远超过2000的文件（列表项）。所以关于这个数字，我的建议是，在你的实际系统中进行一次评估测试，得到一个更实际的结果，这样你会更有把握。任何脱离评估测试的规划都是缺乏说服力的。

4、如果你使用了自定义界面来展现文档库（列表）数据，那么在代码中正确的使用分页查询，你应该可以在列表中直接存放很多的列表项（即使就放在一个文件夹里面），而不太受到性能的影响。

5、即使你像第4条所说的那样，正确的在代码中使用了分页查询，但是也要考虑由于一个文档库中所有的数据都存放在一个网站中，而一个网站位于一个网站集里面，一个网站集只能使用一个Sql Server Database，而不能将其内容分拆存放到多个Database中。这也就意味着，如果一个网站集里面存放的文件数量太多，那么其所在的Database也将变得极其庞大。你也许需要考虑那个Database最终会变得多大，它会占用多大的磁盘空间，会对SQL Server造成何种影响...关于磁盘容量规划，请参考这篇文章。如果你要存放大量的文件，考虑引入EBS或RBS。

6、虽然SharePoint提供了列表，但并不意味着我们应该总是使用列表来替代数据库Table，它们各有各的好处。列表好在提供了一个内置的输入、编辑、展现界面，而且我们可以很容易的为列表数据添加诸如事件处理程序、工作流之类的东东。但是如果你的数据并不需要这些东东，而且大部分界面也需要定制，那么为什么不直接使用数据库Table？

7、如果可能，将文档库（列表）中的数据分区存放。例如，如果你有一个存放“费用报销单”的表单库，那么就可以考虑将3个月之前提交且已经审批完成的表单自动移动到其他文件夹（或其他表单库）里面，表单库的根文件夹则总是只存放最近3个月的表单。数据的自动归档可以使用SharePoint内置的过期管理策略或使用自定义代码来完成。

8、如果是SharePoint 2010系统，那么关于大容量文档库（列表），多了一个List Throttling功能。我会再写一篇blog专门讲述List Throttling。

最后总结，关于这个流言，其结论应该是：PLAUSIBLE。:)