みんな大好き SharePoint の 5,000 件問題ですが、いつも結局のところを忘れてしまうので、備忘録として整理しておきます。
先にこちらの記事を見ておくといろいろ参考になります。
準備
SharePoint に連番と色とサイズの列を持つ簡単なリストを作成します。色は「白」「黒」の 2 種類、サイズは「小」「中」「大」の 3 種類の値が入ります。
アイテム数としては 12,500 件を登録しました。よって、色でフィルターした場合は 6,250 件、サイズでフィルターした場合は 4,166 件が取得できることになります。
色とサイズの列にインデックスがついています。
検証
Postman を使って API を呼び出します。
まずは何もフィルターしない場合です。フィルターがない場合は ID 順に最初の 100 件が取得されます。件数は $top の指定で変更することが可能ですが、5,000 を超える数を指定するとエラーになります。
フィルターにインデックスされていない列を指定した場合はエラーになります。これは内部的にフィルター操作によって 5,000 件を超えるデータを操作しようとするためです。このため、フィルターをする列にはインデックスを指定することが必須になります。
インデックス化されているサイズをフィルターとして指定してみます。検索が成功していることがわかります。
しかし色でフィルターするとエラーになってしまいます。これはフィルターの結果の件数が 5,000 件を超えているためです。つまり、何でもインデックスすればよいというわけではなく、データが分散されることが予想される列をインデックスの対象として選択するべきであることを示しています。
複数条件を指定したときは、結果は 5,000 件以下になるはずですが、これはエラーになります。これはまず色でフィルターされ、その結果に対してサイズのフィルターが処理されるためです。最初のフィルターの結果が 5,000 件を超えるとエラーが発生します。
条件の順番を変更してみると成功することからも動作が理解できると思います。複数条件を指定する際は、できるだけ絞り込みが可能な列を先に指定することでパフォーマンスの改善にも繋がります。
まとめ
以上の検証結果をまとめてみます。
- 5,000 件を超える列のフィルターにはインデックスが必須になる
- インデックスしても結果が 5,000 件を超える場合はフィルターは無効になる
- 複数条件でフィルターする場合は順序を考慮する
「なぜエラーになるのか」の仕組みさえ覚えておけば 5,000 件問題は決して難しくありません。動作を理解しうまく設計してあげることが肝心です。