>という箇所が理解できませんが・・・
>後者も最初は100万件ですよね。
あぁ、失礼致しました。その例示は、後者は「>テーブルの結合」という処理がなく、「>単純計算で1割早い」ことになるという点を強調したつもりでの例示でした。
>また、どちらでも5件の抽出のために必要な90万件の並び替え処理があり、これも負荷の高い処理です。
こういった処理の重さを知らないのでご教示頂けますと大変助かります。ありがとうございます。
ただ、「 “science” にフィルターをかける」なら1割の差ですが「 “science” 以外にフィルターをかける」なら9割の差になります。
この場合でも「>ネットワークなどのオーバーヘッド」と比べれば小さな差だと言えそうでしょうか?
(このことが質問の本旨になります。)
>SQL のパフォーマンスについては WordPress と直接関係がありません
これは失礼致しました。自身の質問内容はWP_Queryという関数によるものにまつわるものだという認識でおりましたゆえ、ご容赦くださいませ。
>しかし、結合するカテゴリ側の件数が非常に少ないことが想定されるので、記事数が100万件を超えていても、それほどの差は無いかもしれません。
この部分が少しわかりませんでした。
すみませんがもう少し教えて頂けませんでしょうか。
先の例はこうでした。
記事が100万件で、カテゴリが10種類
記事が100万件で、投稿タイプが10種類
それぞれの例について、 “science” にフィルターをかけて、9種類が検索対象となったとします。表示記事数は5件です。すると、
前者は100万件を対象に、90万件を抽出し、5件を抽出する
後者は90万件を対象に、5件を抽出する
というように後者の方が10万件分も処理が少ないことになります。にも関わらず、
>カテゴリ側の件数が非常に少ないこと
(つまりカテゴリが10件であること、ですよね?)
という点から、なぜ「>それほど差はない」が帰結されるのでしょうか?
いくつものご指摘に頷くばかりで、大変勉強になります。
仰るとおりですね。どうもありがとうございました。
ちなみに興味からですが、カテゴリは10件で、記事が100万件あったらいかがでしょうか?
ご指摘いただいたような、階層、年月アーカイブ、タグ一覧表示、メニューに並ぶ醜さ、などは考慮せず、ただ記事を取得する速度についてだけお尋ねします。
速度についてだけいえば、カテゴリで分けることと、カスタム投稿タイプで分けることでは、どちらが早いのでしょうか?