get_option（）はget_transient（）にアクセスするよりも高速ですか？

今日、私はdbに対してテストを実行して、オプション、カスタムテーブル、およびトランジェントからのキーへのアクセスの速度の違いを調査します。私はテストを1000回実行しましたが、以下はget操作を1000回実行するのにかかった時間です。

1. get_transient() 0.0245秒
2. get_option() 0.0068秒
3. カスタムテーブルからの単純な選択操作0.65秒

また、このテスト中にトランジェントが期限切れになっていないことを確認しました。だから問題は、テストget_option()よりも速く、get_transient()または私が何かを台無しにしたのですか？WordPressでオプションがデフォルトでキャッシュされるため、カスタムテーブルの遅延はありますか？また、オプションは、トランジェントなどの異なるキャッシュプラグインによってキャッシュされますか？

今日、私はdbに対してテストを実行して、オプション、カスタムテーブル、およびトランジェントからのキーへのアクセスの速度の違いを調査します。私はテストを1000回実行しましたが、以下はget操作を1000回実行するのにかかった時間です。

オプションテーブルはほとんどのシステムでオプションと一時的変数の両方に使用され、そのテーブルはインデックスが追加されて最適化されていることに注意してください。だから、それは公平な比較ではありません

get_transient（）0.0245秒get_option（）0.0068秒カスタムテーブルからの単純な選択操作0.65秒

これは不公平な比較でもあり、autoloadオプションセットのオプションは、早い段階で1つのクエリで事前に読み込まれます。だから、get_optionから引いてWP_Cache、オプションがすでに取得されています。

TLDR：オプションを実際にフェッチするのではなく、すでにフェッチされています。autoloadオプションにより、メモリからプルしているだけです。

また、このテスト中にトランジェントが期限切れになっていないことを確認しました。

これは、一時的な取得で通常のシステムに影響を与えるべきではありません。取得されるまで、有効期限が切れているかどうかはまったくわかりません。

だから問題は、get_option（）がget_transient（）よりも速いのか、それともテストで何かを台無しにしたのか？

場合によります：

• ほとんどのシステムでは、トランジェントはオプションを使用して保存され、どちらもget_option呼び出しを含みます
• autoloadtrueに設定されたオプションはすべて、最初の1回の呼び出しで読み込まれるため、メモリに保持され、その後クエリは発生しません
• オブジェクトキャッシングは、オートロードされたオプションとトランジェントの両方をキャッシュします

WordPressでオプションがデフォルトでキャッシュされるため、カスタムテーブルの遅延はありますか？

非常に可能ですが、選択にかかる時間はクエリとテーブルの設計に大きく依存します

また、オプションは、トランジェントなどの異なるキャッシュプラグインによってキャッシュされますか？

はい、WP_Cache使用されます。これにより、残りのリクエストのためにメモリに保存されます。パフォーマンス上の理由により、キャッシュプラグインはこれらの値を保持する場合があります。

再現性

これらはすべて経由しWP_Cacheてキャッシュされるため、2回目のリクエストではDBは関与しません。

変動性とそれに依存する

これはすべて共通の基礎を前提としていますが、オブジェクトキャッシュはどうですか？

MemcacheDインスタンスまたはRedisインスタンスを紹介しましょう（オプションが用意されている場合は、そうすることを強くお勧めします。特に、ワニス設定のようなものを除いて、ページキャッシングにそれらを使用する場合、十分に構築されたサイトのパフォーマンスが大幅に向上します）

今、私たちは新しい状況にあります：

• データはRAMに保存され、DBからフェッチされると準備され、アクセス時間が大幅に短縮されます。変数よりはまだ遅いが、データベースクエリよりはかなり速い
• 多くの新しいデータが保存されWP_Cacheていますが、通常はそうではありません。たとえば、WP_Postオブジェクト、ポストメタなど
• WP_Cache リクエスト間で持続するようになりました
• MemcacheDなどは期限切れの過渡現象などを排除できます

したがって、トランジェントとオプションのアクセスコストは同じになります。それらはすでに近くにありましたが、それらは現在無視できる程度であり、要求が行われたときのCPU負荷にもっと関係があります。

パフォーマンスのために、トランジェントまたはオプションを使用する必要がありますか？

疑問に思うに値する質問ですが、答えは、その差はごくわずかであり、誤差の範囲内であるということです

したがって、マイクロ最適化を停止してください。これらは同じ記憶媒体であり、これはあなたの時間に値しません

• サイト全体のものを保存する必要がある場合は、オプションを使用します
• トランジェントを使用して、計算にコストがかかるものを一時的に保存して、次回に必要としないようにします

パフォーマンスに基づいてどちらかを選択するのは時間の価値がありません。意味のある違いはありません。

大幅に節約するために最適化するには、はるかに優れた方法があります。たとえば、投稿クエリでメタの代わりに分類法を使用__notする、スタイルパラメータを使用しない、ページで実行する操作を減らす、オブジェクトキャッシュをインストールする、ページごとの投稿を減らす、リモートリクエストを回避する等

次のようなカスタムテーブルはどうなりますか？

いいえ、オプションテーブルは既に十分に最適化されています。カスタムテーブルを使用すると、操作をWPキャッシュシステムの外に移動するだけなので、独自のテーブルを作成する必要があります。

オブジェクトキャッシングが見つからない場合、2回、1回、または有効期間と値の1つをget_transient呼び出すget_optionため、高速にはなりません。

get_optionパフォーマンス自体は、オプションが「自動ロード」（デフォルト）されているかどうかに影響します。自動ロードされたオプションはすべて、DBに対する1つの要求で取得され、メモリキャッシュに格納されるget_optionため、異なるオプションの場合でも、呼び出し回数にほとんど影響がありません。

DBに直接アクセスすると、すべてのキャッシングやその他のパフォーマンスの改善をバイパスします。自分でスマートロジックを実装しない限り、速度は遅くなることが予想されます。

とはいえ、テストが適切であったかどうかはわかりませんが、パフォーマンスに本当に関心がある場合は、データアクセス時間を大幅に短縮するオブジェクトキャッシュシステム（および関連するプラグイン）を使用するので、全体の説明は無意味です。ゼロに..もちろん、独自のDBテーブルを使用する場合は、アクセスAPIをオブジェクトキャッシュメカニズムと統合する必要があります。