SQL_NO_CACHEを使用する場合
私は自分のクエリを検討中です。SELECTクエリでSQL_NO_CACHEを使用する方法についての記事を読んでいます。結局のところ、すべての記事でこれをいつ使用するかについての結論が異なるため、これは私を混乱させました。私が読んだ1つのブログでは、同じクエリがあり、一意である場合はこれを使用する必要があると述べています。別のブログで、決して変化しない情報を抽出する必要がある場合は、このブログを使用する必要があると読みました。
誰かがいつこれを使用するのが良い習慣であるかを説明できますか？私は以前に尋ねられたことは知っていますが、特に人々がさまざまな状況でこの方法を使用するように言っている場合、多くの記事を読んでも役に立たなかった私はいくつかの理論的な状況を作りました、SQL_NO_CACHEを使用することが有益であるかどうか誰かに教えてもらえますか？ありがとうございました。質問が繰り返されたことをお詫びします。私は本当に混乱しています。
Webサイトがその構成（つまり、サイト名、サイトの説明、キーワード）を保存しているとすると、すべてのページで必要なクエリ情報がこの情報を抽出するために要求されます。
ログインチェック中に
userIDを選択すると、クエリはログインチェックプロセス中にのみ実行されます。テーブル
aのフィールドを更新するために、テーブルbからデータを選択します。テーブルaの選択でSQL_NO_CACHEを使用する必要がありますか？
ありがとうございました。
SQL_NO_CACHE
SELECTステートメントのSELECT部分の後、フィールドリストの前にSQL_NO_CACHEを追加するだけです。以下の最初のクエリは、クエリキャッシュが有効で、クエリがキャッシュされている場合に使用します。
SELECT * FROM table WHERE search= 'keyword'; //lets take 1ms
以下の2番目のクエリはクエリキャッシュを使用しません。
SELECT SQL_NO_CACHE * FROM table WHERE search= 'keyword'; //lets take ~0.2ms at 2nd time
これは、クエリをベンチマークするときに特に役立ちます。クエリキャッシュが有効になっている場合、最初のクエリには時間がかかる場合がありますが、2番目以降のクエリはほとんど瞬時です。 SQL_NO_CACHEを使用すると、クエリキャッシュが使用されず、結果時間を安全に比較できます。 SQL_NO_CACHEヒントは、特定のクエリに対してMySQLの組み込みクエリキャッシュメカニズムをオフにします。 MySQLが非常に動的なクエリ（キーワード検索や夜間のみ実行されるレポートなど）にこのヒントを使用することで、クエリキャッシュをより効率的にすることができます。クエリキャッシュがオンになっていることを確認してください。そうでない場合、このコマンドは必要ありません。
SQL_CACHEおよびSQL_NO_CACHEとは？
SQL_CACHEおよびSQL_NO_CACHEオプションは、クエリキャッシュでのクエリ結果のキャッシュに影響します。 SQL_CACHEは、結果がキャッシュ可能で、query_cache_typeシステム変数の値が2またはDEMANDである場合、結果をクエリキャッシュに格納するようMySQLに指示します。 SQL_NO_CACHEを使用すると、サーバーはクエリキャッシュを使用しません。クエリキャッシュをチェックして、結果が既にキャッシュされているかどうかを確認することも、クエリ結果をキャッシュすることもありません。 （パーサーの制限により、SQL_NO_CACHEキーワードの前後にスペース文字が必要です。改行などの非スペースを使用すると、サーバーはクエリキャッシュをチェックして、結果がすでにキャッシュされているかどうかを確認します。）
私の意見によると、「CACHE」が有効になっていて、dbのデータが動的に更新されている場合、つまり、dbデータキャッシュを信頼できない場合は、NO_CACHEを使用できます。データ変更の可能性
役立つシナリオの更新
1）クエリの速度をテストするためにキャッシュを使用しないように強制する
キャッシュを抑制することを選択する最も明白な時間は、クエリ結果をキャッシュに入れたくない場合です（明らかに？）。
クエリを1回だけ実行する場合は、現在キャッシュにあるデータを置き換えて、キャッシュから取得されることのないデータ用のスペースを確保しても意味がありません。
2番目のシナリオは、優先度の低いクエリを実行する場合です。レポートまたは部分的なバックアップを生成する-クエリのパフォーマンスは重要ではありませんが、データベースで発生している他のデータの影響を最小限に抑えることが重要です（キャッシュアクセスの競合に関するいくつかの問題があります）。
3番目のシナリオは、非常に小さなデータセットを返す単純な単一テーブル選択クエリがlotsである場合です（たとえば、トリビアルORMを使用）。このシナリオでは、クエリキャッシングの使用は、完全にバイパスするよりも遅くなる可能性があります。DBMSは、バッファプール/システムキャッシュからデータを読み取るよりも、クエリキャッシュの管理により多くの時間を費やします。
Totが言うように、キャッシュはプロファイリング/ベンチマークを歪めますが、データがバッファリング/キャッシュされる場所はクエリキャッシュだけではありません。
テーブルbのフィールドを更新するために、テーブルaからいくつかのデータを選択します。テーブルaの選択でSQL_NO_CACHEを使用する必要がありますか？
いいえ。基になるデータが変更されると、キャッシュは自動的に無効になります（これにより、単純なクエリのコストの多くが発生します）。
質問に答えるためには、最初にMySQLクエリキャッシュがどのように機能するかを理解する必要があります。これに関する非常に優れた記事が見つかります here 。重要な側面の1つは、キャッシュが データと同期されている であることです。
クエリキャッシュは古いデータを返しません。テーブルが変更されると、クエリキャッシュ内の関連するエントリがすべてフラッシュされます。
あなたのユースケースでは、SQL_NO_CACHEでクエリキャッシュを使用しないという本当の目的は見つかりません。このオプションを使用するために、プロファイリングや制限されたクエリキャッシュへのビッグデータの書き込みを回避するなどの理由がありますが、ここではそうではありません。
使用したのは、クエリのプロファイリング（EXPLAIN extended...）。
クエリを数回実行すると（サーバーを「ウォームアップ」するための非常に重要なインポート手順）、キャッシュされるため、プロファイラーは誤った結果を出力します。
私が使用する状況にもよりますが：
SET SESSION query_cache_type = OFF