WP_Query パラメーターno_found_rows

どういう時に使うか

関連記事3件、サイドバーの新着5件、内部バッチの先頭10件など、次ページを作らないクエリで候補になります。

max_num_pages や found_posts を後から使うコードがないかを検索してから変更します。画面にページ送りがなくても、別処理で総数を参照している場合があります。

件数が少ないテスト環境では差が見えにくいため、本番に近い件数で計測します。

近い引数との違い

posts_per_page は返す件数を制限します。no_found_rows は、その制限とは別に総件数を数える処理を行うかどうかです。

cache_results などのキャッシュ引数とも役割が違います。総数が不要だから省く、という条件がはっきりしている時だけ使います。

Builderでの扱い

WP Query Builder では、ページ送りを使わない設定の時だけ候補として案内できます。常時オンにする高速化スイッチではありません。

ページネーションを有効にしたら警告を出すか、自動的に未指定へ戻すと事故を減らせます。

使いどころ・避けどころと実践確認

次ページや総件数が不要な単発一覧で、総件数計算を省く効果を計測できた時に使います。

ページネーション、全体件数表示、max_num_pages が必要な一覧では true にしません。

取得投稿は表示できてもページ総数が作れなくなるため、速度設定と画面要件を別々に確認します。

一覧が速くなる可能性と引き換えに総ページ数を失うため、ページ送りを出さない画面だけが候補です。

同じ条件で found_posts、max_num_pages、データベース問い合わせ回数、表示された投稿IDを指定前後に比較し、失う情報を記録します。

実践記事で確認WP_Queryでページネーションがうまく動かない原因

ページ総数が0または1になる症状と、no_found_rows を使えない条件を実例で確認できます。

記事を読む →

WordPressの仕様で確認するポイント

公式の WP_Query リファレンスでは、総件数が不要な時に true を使う性能上の意図を確認できます。

WP_Query の set_found_posts() がこの値で処理を終了することも、実装上の根拠になります。

最後は、値を変える目的と、変えた時に失う情報を一緒に確認します。