SharePoint服务器端对象模型 之 使用CAML进行数据查询(Part 4)

(五)列表查询中的阈值限制

在之前版本的SharePoint 中,如果在查询的时候没有指定返回数目,那么SharePoint将会查找该列表中所有的条目,这可能会造成在SQL表中需要返回大量的条目,极大影响了数据库的I/O性能和网络负载,如果返回的条目数量超过一定范围之后,SQL Server会把整张数据表锁定。我们知道在SharePoint中,所有的列表条目信息都是存储在同一张SQL Server数据表中的,这也就意味着,一个设计的不好的列表查询,可能会导致整个SharePoint的其他应用都停止响应。

为了避免这些有缺陷的程序可能对网站其余功能的使用造成的影响,在SharePoint 2010中,引入了列表查询的阈值限制。在管理中心的“Web应用程序管理”—“常规设置”—“资源限制”设置中,我们可以看到如下的设置:

image

从设置中我们看到SharePoint对列表数据的查询返回可以进行如下一些设置:

1、数量限制

在默认情况下,SharePoint在返回列表条目的时候,会进行数量的限制。对于普通用户,一次返回列表条目不能超过5000个,对于有一定条件的管理员则不能超过20000个。这两个阈值可以在上述界面中进行设置,设置的范围是从2000到Int32.MaxValue。如果在查询中返回超过了这个阈值的条目,则程序会终止查询,并抛出一个类型为“SPQueryThrottledException”的异常,异常的信息为“不允许执行所尝试的操作,因为它已超过管理员规定的列表视图阈值。”,从而阻止用户可能对服务器性能造成严重影响的操作。

2、查阅项限制

SharePoint的查阅项虽然在页面中以及在程序中看起来都能够查看到所查阅条目相应字段的信息,但是查阅项在数据库中存储的时候,是只保存所查阅条目的ID值的。这也就意味着,在列表显示或者自定义的程序中,每获取一次查阅项,就要多付出一些额外的数据库操作时间。如果列表中包含很多查阅项,对服务器的性能同样可能造成影响。

因此,SharePoint 2010在列表条目返回的时候,对所返回的查阅项的数量也进行了限制,默认是6个查阅项。如果我们在SPView、SPQuery或SPSiteDataQuery的ViewFields属性中显式指定了超过该阈值的查阅项字段的时候,在查询返回后同样会抛出一个“SPQueryThrottledException”异常,异常信息为“查询无法完成,因为其包含的查找列数已超过管理员强制实施的查找列阈值。”;而如果没有指定ViewFields属性,当当返回的一个列表条目中超过指定个数的查阅项的时候,阈值个数之后查阅项字段会被抛弃掉,视为该字段不存在。

但需要特别注意,列表中的查阅项、人员和组以及工作流状态字段都会计入这个查阅项限制中,因为这些字段类型的本质都是从另外的列表中进行信息的引用。

3、大型查询时间

在某些时候,我们的确需要在服务器比较空闲的时候执行一些统计性的非常耗时的工作,其中可能会返回大量的数据结果,SharePoint 2010也为我们开放了这样一个选择:开启大型查询的每日时间段,指定在每天的固定几个小时中,可以在查询过程中不受上述阈值限制的影响。

4、使用对象模型替代

在一些特殊的应用中,我们可能确实需要在查询的时候,返回超过阈值限制的列表条目、或者超过查阅项限制的字段数目。SharePoint在查询相关的对象模型中,提供了一个属性,可以控制以何种方式来替代Web应用程序中的查询资源限制。

如果在资源限制设置中,开启了“允许对象模型替代”选项,那么我们可以通过SPQuery以及SPSiteDataQuery的QueryThrottleMode属性,来控制查询的时候使用什么样的规则进行阈值控制,该属性是一个枚举类型(SPQueryThrottleOption),包含的属性及其含义如下:

属性

规则

Default

如果当前用户是本地管理员,则在查询返回结果的时候不受任何阈值限制。否则,数量限制和查阅项限制都回对查询造成影响。这个选择也是默认值。

Override

如果当前用户是本地管理员,则在查询返回结果的时候不受任何阈值限制。如果当前用户在Web应用程序的策略中被指定为“完全读取”或“完全控制”(通常是作为审计用户及管理员),那么在查询返回结果的时候,会受到数量阈值的限制,但是不会受到查阅项阈值的限制。对于其他用户,两种限制都是生效的。

Strict

不论当前用户是何种权限和角色,在查询返回结果的时候都要受到数量限制和查阅项限制。

通过这一设置,我们就可以在编写自定义程序的时候,根据不同角色的不同需要,灵活控制代码在执行查询时候的阈值限制,从而在满足需求的情况下尽可能少的对服务器上的其他应用造成性能上的影响。

posted on 2015-05-01 21:29  Erucy  阅读(...)  评论(...编辑  收藏

导航