実行されたクエリがMySQLクエリキャッシュから取得されているかどうかを確認する方法はありますか？
もちろん...一般的なレベル（SHOW STATUS LIKE '%qcache%'など）でキャッシュされたクエリの数を数える方法はたくさんありますが、現在実行されているクエリがMySQLキャッシュからロードされているかどうかを具体的に知りたいです。
たとえば、PHPでは、関数mysql_insert_id();は最後に挿入されたIDを別のクエリで返します。
mysql_is_query_from_cache($previous_query);その方向では、以前のクエリ結果が実際にMySQLクエリキャッシュから取得されていることを確認するようなメタデータ関数を呼び出すのは素晴らしいことです。
これについて何かアイデアはありますか？
MySQL 5.0以降では、SHOW PROFILESを使用して最近のクエリIDのリストを取得し、SHOW PROFILE FOR QUERY％id_here％を使用して、キャッシュされたデータへの参照があったかどうかを確認できます。
これについては、 http： //www.dbasquare.com/2012/04/03/was-a-query-served-from-mysql-query-cache/やその他の方法で詳しく説明されています。
@yuriyに感謝します。「SHOWPFOFILE」の提案を使用してコードサンプルを作成しました。これは魅力のように機能します。'SHOW PROFILE FOR QUERY 2'コマンドは、「キャッシュされた結果をクライアントに送信する」という非常にきれいな結果をもたらします。これはまさに私が探していたトリガーでした。:)
/* enable profiling */
$result = mysql_query('SET profiling = 1');
/* is profiling ON for this session? */
$result = mysql_query("SHOW VARIABLES LIKE '%profiling%'");
/* execute main query */
$result = mysql_query('SELECT COUNT(*) FROM orders');
/* show overview of current profiles */
$result = mysql_query('SHOW PROFILES');
/* show profiling stats for main query */
$result = mysql_query('SHOW PROFILE FOR QUERY 2');
たとえば、同じクエリを2回実行して、それらのプロファイルを確認できます。
set global query_cache_size = 16777216;
set profiling = 1;
クエリを2回実行する
select * from sbtest.sbtest1 limit 100;
select * from sbtest.sbtest1 limit 100;
次にプロファイルを確認すると、2番目のクエリのコストが最初のクエリよりも短いことがわかります
mysql> show profiles;
+----------+------------+----------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+----------------------------------------+
| 7 | 0.20415325 | set global query_cache_size = 16777216 |
| 8 | 0.26780725 | select * from sbtest.sbtest2 limit 100 |
| 9 | 0.00007350 | select * from sbtest.sbtest2 limit 100 |
+----------+------------+----------------------------------------+
「クエリIDのプロファイルを表示」を使用して、query_ID = 8（最初のクエリ）およびquery_ID = 9（2番目のクエリ）と比較します。
mysql> show profile for query 8;
+--------------------------------+----------+
| Status | Duration |
+--------------------------------+----------+
| starting | 0.000023 |
| Waiting for query cache lock | 0.000004 |
| checking query cache for query | 0.032402 |
| checking permissions | 0.000088 |
| Opening tables | 0.000035 |
| System lock | 0.000014 |
| Waiting for query cache lock | 0.049689 |
| init | 0.075707 |
| optimizing | 0.000015 |
| statistics | 0.000021 |
| preparing | 0.000012 |
| executing | 0.000004 |
| Sending data | 0.108332 |
| Waiting for query cache lock | 0.000013 |
| Sending data | 0.000581 |
| end | 0.000012 |
| query end | 0.000062 |
| closing tables | 0.000020 |
| freeing items | 0.000013 |
| Waiting for query cache lock | 0.000003 |
| freeing items | 0.000741 |
| Waiting for query cache lock | 0.000006 |
| freeing items | 0.000002 |
| storing result in query cache | 0.000005 |
| logging slow query | 0.000003 |
| cleaning up | 0.000004 |
+--------------------------------+----------+
26 rows in set (0.49 sec)
開いているテーブル、閉じているテーブルなどの長いリストが表示されます。これは、このクエリがハードディスクからデータをクエリする必要があることを意味し、2番目のリストは
mysql> show profile for query 9;
+--------------------------------+----------+
| Status | Duration |
+--------------------------------+----------+
| starting | 0.000023 |
| Waiting for query cache lock | 0.000004 |
| checking query cache for query | 0.000008 |
| checking privileges on cached | 0.000003 |
| checking permissions | 0.000010 |
| sending cached result to clien | 0.000019 |
| logging slow query | 0.000003 |
| cleaning up | 0.000003 |
+--------------------------------+----------+
8 rows in set (0.00 sec)
クエリがキャッシュされていることを証明します
これに注意してください。
SELECT * FROM orders;
キャッシュからではありません（クエリID = qId1）
SELECT * FROM orders;
キャッシュからのものです（クエリIDが変更されます！、クエリID = qId2）
DELETE FROM orders;
id = qId2のクエリはキャッシュからのものですが、実際にはそうではありません。（テーブルデータの変更）。もう一度クエリを実行する必要があります。ただし、実行する前に、クエリがキャッシュからのものであるかどうかを知る必要があります。そしてそれがYuriyの方法が機能しない理由です。