カスタム投稿タイプを使用する際のパフォーマンスに関する考慮事項はありますか？
10のカスタム投稿タイプに分けられた約10,000の投稿を含む忙しいサイトを考えてみましょう。カスタム分類法とカスタムフィールドもそれらすべてに使用されます。
メインのクエリは、インデックス、アーカイブ、検索、フィードなど、あらゆる場所にこれらの投稿タイプをすべて含めるように変更されました。
さて、通常の '投稿'に対してカスタム投稿タイプを使用したことによるパフォーマンスへの影響はありますか？ またはそれは彼らがどんなタイプであるかに違いを生じないでしょうか？
いいえ。すべての投稿はwp_postsテーブルに格納されています。投稿タイプはpost_type列で定義されています。
クエリに含まれるカスタム投稿タイプに関係なく、実行されるSQLクエリは1つだけです。もちろん、少し複雑なクエリ（in vs. =）によってパフォーマンスが低下する可能性がありますが、それはごくわずかです。
いいえ、意味のあるパフォーマンスの違いはありません 。
- それらはすべて同じ方法で内部的に保存されています
- それらはすべて同じ方法で照会されています
すべてのクエリは投稿タイプのクエリです。どちらを指定しない場合はpostが使用されます。組み込みの投稿タイプはカスタム投稿タイプに比べて特別なパフォーマンス上の利点はありません。
違いはありません、CPTは「通常の」投稿と同じwp_postsテーブルに格納されています - ここでほとんどの回答で言及されています - ただし、パフォーマンスが影響を受ける場所は{canです。 postmeta（カスタムフィールド）をたくさん保存するのであれば - 最高のパフォーマンスを得るために - postmetaに "lot"を保存しないようにしてください - できる限りカスタム分類法を使用してください。
私は400,000〜500,000の投稿があるサイトを処理しましたが、うまく機能します。カスタム分類法やカスタムフィールドの使用法に関係なく、10,000の投稿はWordPressが処理するものではありません。
WordPressはポストメタデータを処理するための非常に成熟したアーキテクチャを持っており、組み込み関数と手続きはデータのロードを処理するのに十分に優れています。
WordPressはpage、post、<custom-post-types>を同じように格納します。それらはwp_postテーブルに格納され、post_typeフィールドはそれらを区別します。メタデータはwp_postmetaテーブルに格納され、各カスタムフィールドはmeta_keyによって識別され、post_idフィールドによって投稿にリンクされます。
唯一のパフォーマンスの問題は、それらを取得する方法です。カスタムクエリを最大限に最適化することがパフォーマンスの問題を解決することです。