クエリは解析前に比較されるため、

SELECT * FROM tbl_name

と

Select * from tbl_name

は、クエリキャッシュで別のクエリとみなされます。完全に一致する（各バイトが）クエリ以外、同一とはみなされません。 また、たとえば、あるクライアントで新しい形式の通信プロトコルを使用している場合や、別のクライアントが使用しているものとは異なるキャラクタセットを使用している場合も、同じものであるはずのクエリが異なるものとして認識されることがあります。

異なるデータベースを使用するクエリや、使用プロトコルのバージョンが異なるクエリ、またデフォルトのキャラクタセットが異なるクエリは、いずれも異なるクエリとして認識され、別々にキャッシュされます。

キャッシュは SELECT SQL_CALC_FOUND_ROWS ... および SELECT FOUND_ROWS() ... 型のクエリでも機能します。これは、検出されたレコードの数もキャッシュに格納されるためです。

クエリの結果がクエリキャッシュから返された場合、ステータス変数 Com_select の値は増加しませんが、Qcache_hits の値は増加します。 See 項6.9.4. 「クエリキャッシュのステータスと保守」。

テーブルが変更されると（INSERT、UPDATE、DELETE、TRUNCATE、ALTER、DROP TABLE|DATABASE のいずれかによって）、そのテーブルを（場合によっては、MRG_MyISAM テーブルを通して）使用したキャッシュ内のクエリはすべて無効になり、キャッシュから削除されます。

変更された InnoDB トランザクションテーブルは、COMMIT が実行されると無効化されます。

MySQL 4.0 では、クエリキャッシュはトランザクション内では無効です（結果は返されません）。MySQL 4.1.1 以降では、InnoDB テーブルの使用時、クエリキャッシュはトランザクション内でも機能します（テーブルのバージョン番号に基づいて、データがまだカレントかどうかが検出されます）。

MySQL 5.0 より前のバージョンでは、先行するコメントで始まるクエリの場合、キャッシュへの格納は可能でも、キャッシュから取得できませんでした。この問題は MySQL 5.0 で修正されています。

次の関数のいずれかを含んでいるクエリは、キャッシュできません。

また、ユーザ変数を含んでいるクエリ、mysql システムデータベースを参照しているクエリ、SELECT ... IN SHARE MODE、SELECT ... INTO OUTFILE ...、SELECT ... INTO DUMPFILE ... のいずれかの形式のクエリ、および SELECT * FROM AUTOINCREMENT_FIELD IS NULL 形式のクエリ（最後に挿入された ID の取り出し - ODBC 回避策）についても、キャッシュできません。

ただし、FOUND_ROWS() は、先行するクエリがキャッシュからフェッチされたものであっても正しい値を返します。

クエリでテーブルを何も使用しない、またはテンポラリテーブルを使用する場合や、関連するテーブルのいずれかに対するカラムのアクセス権限をユーザが持っていない場合、クエリはキャッシュされません。

MySQL では、クエリをクエリキャッシュから読み取る前に、関連するすべてのデータベースとテーブルに対する SELECT 権限をユーザが持っているかチェックします。この権限をユーザが持っていない場合、キャッシュに格納されている結果は使用されません。