SPQueryはリストビューのしきい値の下のライブラリに機能しますが、終了しません

Question

SO現在のWebのすべてのDOCLIBを列挙して、チェックアウトされたファイルをすべて掴んでテーブル内のリストを表示し、ユーザーがいくつかの必要なメタデータを適用し、一度に多くの場合（50）。

このWebPartは、リストビューのしきい値（現在は15,000で設定されている）、および非常に大きいサイト（50,000~100,000以上のドキュメント）上でリストを操作する必要があります。

ここで大規模なリストを処理するためのMSベストプラクティスをフォローしています。 http： //msdn.microsoft.com/en-us/library/ee557257.aspx

（CAMLがまったく定義されていない）、2,000項目のページを取得してその方法を解析します。これに関する問題は、実際にWebPartが実際にそれらの非常に大きい（50k +）サイトでタイムアウトを発生させていることです。だから私は私のCAMLと少し賢くなっていることを試みて、チェックアウトされているアイテムのみを引いてください：

spQuery.Query = "<Where><IsNotNull>
    <FieldRef Name=\"CheckoutUser\" LookupId=\"TRUE\"/>
</IsNotNull></Where>";
spQuery.RowLimit = 2000;
spQuery.ViewAttributes = "Scope=\"Recursive\"";

.

これと同じCAMLを使用してWeb全体を照会するためにCrossListQueryInfoクエリを使用しています。 1つがある場合は、その例外をキャッチして、各個々のライブラリの「遅い」SPQueryで再試行してください。

私が読んでいるすべてのものから、私のCamlがLVTよりも少ないアイテムを返している限り、それはうまくいくべきです。しかし、上のCAMLを使用すると、The attempted operation is prohibited because it exceeds the list view threshold enforced by the administratorが呼び出されたときにエラーSPList.GetItems(spQuery)がスローされます。私は2,000の行を設定しているので、それは決して起こらないではありませんか？ MSは、まったく定義されていないCAMLを使用してSPQueryを実行することを提案します - 基本的にライブラリから2,000のページですべての項目をつかみます。だから私は私のCAMLがビューしきい値を覆ってリストでのみ失敗している理由を理解することはできません。

編集：さらなる研究の際に、私はContentIteratorクラスを私のニーズに応えることを試みています（ http://msdn.microsoft.com/en-us/library/microsoft.office.server.utilities.ContentIterator.aspx ）この投稿からの例を使用して： http：// recthive- sharepoint.com/2012/07/17/data-access-via-caml-queries/

私はまだ同じLVTエラーを持つContentIteratorで失敗しています。

'checkoutuser'フィールドは、このクエリを実行したいすべてのリストに索引付けする必要がありますか？

Update 2：これは、索引付けされていない 'checkoutuser'フィールドに登録され、それに照会しようとしています。残念ながらそれは私たちが外出し、農場のすべての図書館にこの指標を強制するための選択肢ではありません。私はこの時点で私の唯一の選択肢は、バッチ内のアイテムを処理するために非常に大きなサイトにある種のページングスキームを実装することです。

最終更新：解決策として、私はライブラリの 'checkoutuser'列の索引付けを強制することにしました。これにより、WebPartの全体的なパフォーマンスが大幅に向上し、非常に大きなサイトをサポートできます。リストビューのしきい値を介してリストの列インデックスを手動で設定する必要があるため、展開後の少しのヘッドカッシュが表示されますが、長時間実行中は最適です。

Answer 1

リストビューのしきい値が機能している方法についての私の理解は、私はあなたのCAMLクエリが失敗している理由が疑われる理由は、インデックスが非インデックスフィールドでフィルタリングされているため、RowLimitが "After"に適用されます。

チェックアウトャのフィールドの索引付けはあなたの問題を解決するだろうと思いますが、それはあなたがたくさんのサイトを持っているように聞こえます。

代替アプローチページングを提案できるようにします。すべてのリストのID列は索引付けされているので、ID列の最初の（非常に重要）、つまり2000、およびCheckoutUserフィールドに最初にフィルタリングしているCAMLクエリを実装します。そのクエリが希望の数の結果を返さない場合は、2000から4000を増やし、繰り返します。

私はこの解決策を自分で実装していない、それはただの考えです。

Answer 2

大規模なリストを照会している場合は、照会しているフィールドに間違いなく索引付けする必要があります。インデックス付きフィールドはデータベース内の別のテーブルに格納されているため、スロットルは発生しません。

私のこのブログの投稿は私が考えるのに役立つものであるべきです： > http://vrdmn.blogspot.in/2012/11/sharepoint-list-indexes-eromesthood.html