关于“超出管理员强制要求的列表阈值”
其中第一个问题极大的限制了SharePoint的应用场景，很多用户都看过那篇著名的白皮书（链接我就不给了），也听过很多我们讲的课程，都会对两个数字有非常深刻的印象：2000和20000——这是在白皮书中的两个建议数值：一个视图/文件夹中的条目不要超过2000，一个列表中的条目不要超过20000。当然，这只是一个建议，KB同学在这篇BLOG（点我点我）中对这个数字进行了一个具体的说明。今天我们主要不是想讨论这两个数字，而是谈一下在SharePoint 2010中对列表性能问题的改进。
首先，按照微软的官方说法，在SharePoint 2010中，一个列表中可以支持到千万数量级的条目（你没看错，是千万数量级，和之前有了质的飞跃），不过前提条件是要做好列表容量规划。在2010的管理中心 - Web应用程序管理 - 资源限制 页面中，我们看到2010中新增的对于列表的一些阈值限制，其中最重要的第一个限制，就是列表视图阈值，默认设置为5000个（见下图）。
在SharePoint的在线帮助文档中对5000这个数字的来历有一个解释（这同时也解释了为什么在2007里面如果一个列表内容多了会造成性能的极大影响），摘录如下：为了最大程度地减少数据库争用，SQL Server 经常使用行级锁定策略来确保在不对访问其他行的其他用户产生负面影响的情况下准确地进行更新。但是，如果某个读取或写入的数据库操作（如查询）导致一次锁定 5,000 个以上的行，则让 SQL Server 暂时将锁定升级至整个表，直至数据库操作完成，会更加有效。请注意，实际数目并非始终为 5,000，该数目可能会因您的网站、数据库中的活动量以及网站配置而异。如果执行此锁定升级，其他用户将无法访问该表。如果此锁定升级经常发生，则所有用户都会遇到系统性能下降的情况。因此，若要帮助最大程度地降低资源密集型数据库操作的影响并平衡所有用户的需要，阈值和限制是必不可少的。
因此在2010中，SharePoint一旦发现用户在查询视图的时候，查询结果有可能超过5000，就会出现故事一开头的那两个错误。这个设置能够阻止一些可能会对服务器整体性能造成影响的用户操作，免得因为个别用户的操作影响到其他用户的正常使用。
介绍到这里，我们再来关心一下如何解决这个问题。回到故事的场景中：课程预订的列表条目终于超过了5000，但其实每个用户自己并不需要查看所有的课程预订记录（管理员除外），只关心自己预订的课程就够了。因此，在“我的课程”视图和课程预订的时候，都是先按照“创建者”进行了一层筛选，仅显示出当前用户所创建的课程预订记录。
那么为了解决上面的问题，只需要对“创建者”这个字段创建一个索引就好了（进入到列表设置页面，管理索引，加入“创建者”）。
当SharePoint判断到当前视图的第一个筛选条件（注意：只是第一个）设置过索引的时候，这个5000阈值数的限制，就不是针对整个列表的条目了，而是针对在这个索引字段下，所查询出的结果条目数。一个用户可能预订超过5000节课程嘛？当然不可能，一共都没这么多课。因此，在修改了这一设置之后，系统就可以一往如前的运行了，只是在课程预订的时候，要稍稍慢一点点，让SharePoint有时间去维护自己的索引。
故事在这里就告一段落了，不过事情并没有结束。
在管理中心的“资源限制”界面中，还有一些相关设置和这个阈值数目是有关的，这些设置主要针对如下的一些场景：
场景一：我是管理员，我需要有特权。
不错，管理员在系统中确实会有一些有别于普通用户的操作，比如查看所有用户预订的课程，这个时候如果还按照5000阈值数目进行限制，就显得太不合情理了。SharePoint针对管理员单独提出了另外一个阈值，这个值默认是20000（一个熟悉的数字），只要在管理员的视图中，经过索引栏过滤之后，结果总数不超过20000，管理员就可以正常工作了。
场景二：我是后台程序，我需要一些特别操作。
对于人来讲，总数20000基本上已经足够看的了，而对于一些机器运行的程序而言，20000这个数量还远远不够班。例如，我们需要每天晚上针对所有用户预订的课程进行一次统计分析，这种可怕的数据量查询可能并不会对一般的用户造成影响（除了那些熬夜打游戏，偶尔上一下网站的夜猫子），因此，SharePoint专门可以设置一个时间段，在这个时间段内，用户的查询不采用任何的阈值限制，可以随意运行程序或操作。
转：http://blog.joycode.com/erucy/archive/2010/08/09/116040.joy
