MySQLで使ってないインデックスを調べる方法

MySQL5.5から統計情報を収集するperformance_schemaというテータベースが利用できるようになりました。そしてMySQL5.6ではperformance_schemaデータベース内にtable_io_waits_summary_by_index_usageというテーブルが追加されていました。

え!?これってもしかしてインテックスの使用状況がわかるんじゃない?って期待が頭をよぎりましたので調べてみました。

検証テーブル作成

今回検証した環境ではtestデータベースが残ってましたので、そこに検証用テーブルを作成しました。

mysql> use test
Database changed
mysql> CREATE TABLE `t1` (
    ->     `c1` int AUTO_INCREMENT,
    ->     `c2` int,
    ->     `c3` int,
    ->     `c4` int,
    ->     PRIMARY KEY (`c1`),
    ->     KEY `c2_idx` (`c2`),
    ->     KEY `c3_idx` (`c3`)
    -> ) ENGINE=InnoDB;
Query OK, 0 rows affected (0.02 sec)

mysql> INSERT INTO `t1` (`c2`,`c3`,`c4`) VALUES (0,0,0),(1,1,1),(2,2,2),(3,3,3),(4,4,4),(5,5,5),(6,6,6),(7,7,7),(8,8,8),(9,9,9);
Query OK, 10 rows affected (0.00 sec)
Records: 10  Duplicates: 0  Warnings: 0

テーブルを作成するとperformance_schemaに早速情報が追加されます。

mysql> SELECT
    ->     *
    ->  FROM
    ->     performance_schema.table_io_waits_summary_by_index_usage
    -> WHERE
    ->     OBJECT_SCHEMA LIKE 'test'\G
*************************** 1. row ***************************
     OBJECT_TYPE: TABLE
   OBJECT_SCHEMA: test
     OBJECT_NAME: t1
      INDEX_NAME: PRIMARY
      COUNT_STAR: 0
  SUM_TIMER_WAIT: 0
  MIN_TIMER_WAIT: 0
  AVG_TIMER_WAIT: 0
  MAX_TIMER_WAIT: 0
      COUNT_READ: 0
  SUM_TIMER_READ: 0
  MIN_TIMER_READ: 0
  AVG_TIMER_READ: 0
  MAX_TIMER_READ: 0
     COUNT_WRITE: 0
 SUM_TIMER_WRITE: 0
 MIN_TIMER_WRITE: 0
 AVG_TIMER_WRITE: 0
 MAX_TIMER_WRITE: 0
     COUNT_FETCH: 0
 SUM_TIMER_FETCH: 0
 MIN_TIMER_FETCH: 0
 AVG_TIMER_FETCH: 0
 MAX_TIMER_FETCH: 0
    COUNT_INSERT: 0
SUM_TIMER_INSERT: 0
MIN_TIMER_INSERT: 0
AVG_TIMER_INSERT: 0
MAX_TIMER_INSERT: 0
    COUNT_UPDATE: 0
SUM_TIMER_UPDATE: 0
MIN_TIMER_UPDATE: 0
AVG_TIMER_UPDATE: 0
MAX_TIMER_UPDATE: 0
    COUNT_DELETE: 0
SUM_TIMER_DELETE: 0
MIN_TIMER_DELETE: 0
AVG_TIMER_DELETE: 0
MAX_TIMER_DELETE: 0
*************************** 2. row ***************************
     OBJECT_TYPE: TABLE
   OBJECT_SCHEMA: test
     OBJECT_NAME: t1
      INDEX_NAME: c2_idx
      COUNT_STAR: 0
  SUM_TIMER_WAIT: 0
  MIN_TIMER_WAIT: 0
  AVG_TIMER_WAIT: 0
  MAX_TIMER_WAIT: 0
      COUNT_READ: 0
  SUM_TIMER_READ: 0
  MIN_TIMER_READ: 0
  AVG_TIMER_READ: 0
  MAX_TIMER_READ: 0
     COUNT_WRITE: 0
 SUM_TIMER_WRITE: 0
 MIN_TIMER_WRITE: 0
 AVG_TIMER_WRITE: 0
 MAX_TIMER_WRITE: 0
     COUNT_FETCH: 0
 SUM_TIMER_FETCH: 0
 MIN_TIMER_FETCH: 0
 AVG_TIMER_FETCH: 0
 MAX_TIMER_FETCH: 0
    COUNT_INSERT: 0
SUM_TIMER_INSERT: 0
MIN_TIMER_INSERT: 0
AVG_TIMER_INSERT: 0
MAX_TIMER_INSERT: 0
    COUNT_UPDATE: 0
SUM_TIMER_UPDATE: 0
MIN_TIMER_UPDATE: 0
AVG_TIMER_UPDATE: 0
MAX_TIMER_UPDATE: 0
    COUNT_DELETE: 0
SUM_TIMER_DELETE: 0
MIN_TIMER_DELETE: 0
AVG_TIMER_DELETE: 0
MAX_TIMER_DELETE: 0
*************************** 3. row ***************************
     OBJECT_TYPE: TABLE
   OBJECT_SCHEMA: test
     OBJECT_NAME: t1
      INDEX_NAME: c3_idx
      COUNT_STAR: 0
  SUM_TIMER_WAIT: 0
  MIN_TIMER_WAIT: 0
  AVG_TIMER_WAIT: 0
  MAX_TIMER_WAIT: 0
      COUNT_READ: 0
  SUM_TIMER_READ: 0
  MIN_TIMER_READ: 0
  AVG_TIMER_READ: 0
  MAX_TIMER_READ: 0
     COUNT_WRITE: 0
 SUM_TIMER_WRITE: 0
 MIN_TIMER_WRITE: 0
 AVG_TIMER_WRITE: 0
 MAX_TIMER_WRITE: 0
     COUNT_FETCH: 0
 SUM_TIMER_FETCH: 0
 MIN_TIMER_FETCH: 0
 AVG_TIMER_FETCH: 0
 MAX_TIMER_FETCH: 0
    COUNT_INSERT: 0
SUM_TIMER_INSERT: 0
MIN_TIMER_INSERT: 0
AVG_TIMER_INSERT: 0
MAX_TIMER_INSERT: 0
    COUNT_UPDATE: 0
SUM_TIMER_UPDATE: 0
MIN_TIMER_UPDATE: 0
AVG_TIMER_UPDATE: 0
MAX_TIMER_UPDATE: 0
    COUNT_DELETE: 0
SUM_TIMER_DELETE: 0
MIN_TIMER_DELETE: 0
AVG_TIMER_DELETE: 0
MAX_TIMER_DELETE: 0
*************************** 4. row ***************************
     OBJECT_TYPE: TABLE
   OBJECT_SCHEMA: test
     OBJECT_NAME: t1
      INDEX_NAME: NULL
      COUNT_STAR: 10
  SUM_TIMER_WAIT: 131590155
  MIN_TIMER_WAIT: 5567885
  AVG_TIMER_WAIT: 13158815
  MAX_TIMER_WAIT: 63245720
      COUNT_READ: 0
  SUM_TIMER_READ: 0
  MIN_TIMER_READ: 0
  AVG_TIMER_READ: 0
  MAX_TIMER_READ: 0
     COUNT_WRITE: 10
 SUM_TIMER_WRITE: 131590155
 MIN_TIMER_WRITE: 5567885
 AVG_TIMER_WRITE: 13158815
 MAX_TIMER_WRITE: 63245720
     COUNT_FETCH: 0
 SUM_TIMER_FETCH: 0
 MIN_TIMER_FETCH: 0
 AVG_TIMER_FETCH: 0
 MAX_TIMER_FETCH: 0
    COUNT_INSERT: 10
SUM_TIMER_INSERT: 131590155
MIN_TIMER_INSERT: 5567885
AVG_TIMER_INSERT: 13158815
MAX_TIMER_INSERT: 63245720
    COUNT_UPDATE: 0
SUM_TIMER_UPDATE: 0
MIN_TIMER_UPDATE: 0
AVG_TIMER_UPDATE: 0
MAX_TIMER_UPDATE: 0
    COUNT_DELETE: 0
SUM_TIMER_DELETE: 0
MIN_TIMER_DELETE: 0
AVG_TIMER_DELETE: 0
MAX_TIMER_DELETE: 0
4 rows in set (0.01 sec)

取得したレコードの内容はリファレンスマニュアルに書いてありました。

The structure of table_io_waits_summary_by_index_usage is nearly identical to table_io_waits_summary_by_table. The only difference is the additional group column, INDEX_NAME, which corresponds to the name of the index that was used when the table I/O wait event was recorded:

  • A value of PRIMARY indicates that table I/O used the primary index.
  • A value of NULL means that table I/O used no index.
  • Inserts are counted against INDEX_NAME = NULL.

table_io_waits_summary_by_index_usageの構造はtable_io_waits_summary_by_tableとほぼ同一です。唯一の違う点はINDEX_NAMEというカラムが追加されており、これはテーブルI/O待機イベントが記録された時に使用されるインデックスの名前と一致します。

  • 値がPRIMARYのものはテーブルI/Oがプライマリーインデックスを使用したことを表します。
  • 値がNULLのものはテーブルI/Oがインデックスを使用しなかっとことを意味します。
  • 挿入はINDEX_NAME = NULLに対してカウントされます。

引用元: MySQL 5.6 Manual : 22.9.9.6.2 The table_io_waits_summary_by_index_usage Table

ということらしいです。10行インサートしたので、INDEX_NAME = NULLの行のCOUNT_INSERTが10になっているんですね。多分。

ということはインデックスが使用された場合は対象の行のCOUNT_READが増えていくはず。やってみます。

っていうかSUM_TIMER_WRITEとかMIN_TIMER_WAITの値って何なんでしょうか。マイクロ秒??ナノ秒??よくわからんですが、実行時間を何かしらの数値化したものということは間違いないはず。

インデックスを使った検索

ということでインデックスを使った検索をやってtable_io_waits_summary_by_index_usageの対象の行の値がどうなるか確認してみます。

mysql> SELECT * FROM `t1` WHERE `c2` = 1;
+----+------+------+------+
| c1 | c2   | c3   | c4   |
+----+------+------+------+
|  2 |    1 |    1 |    1 |
+----+------+------+------+
1 row in set (0.00 sec)
mysql> SELECT
    ->     *
    -> FROM
    ->     performance_schema.table_io_waits_summary_by_index_usage
    -> WHERE
    ->     OBJECT_SCHEMA LIKE 'test'
    ->     AND INDEX_NAME LIKE 'c2_idx'\G
*************************** 1. row ***************************
     OBJECT_TYPE: TABLE
   OBJECT_SCHEMA: test
     OBJECT_NAME: t1
      INDEX_NAME: c2_idx
      COUNT_STAR: 2
  SUM_TIMER_WAIT: 16503155
  MIN_TIMER_WAIT: 1154880
  AVG_TIMER_WAIT: 8251377
  MAX_TIMER_WAIT: 15348275
      COUNT_READ: 2
  SUM_TIMER_READ: 16503155
  MIN_TIMER_READ: 1154880
  AVG_TIMER_READ: 8251377
  MAX_TIMER_READ: 15348275
     COUNT_WRITE: 0
 SUM_TIMER_WRITE: 0
 MIN_TIMER_WRITE: 0
 AVG_TIMER_WRITE: 0
 MAX_TIMER_WRITE: 0
     COUNT_FETCH: 2
 SUM_TIMER_FETCH: 16503155
 MIN_TIMER_FETCH: 1154880
 AVG_TIMER_FETCH: 8251377
 MAX_TIMER_FETCH: 15348275
    COUNT_INSERT: 0
SUM_TIMER_INSERT: 0
MIN_TIMER_INSERT: 0
AVG_TIMER_INSERT: 0
MAX_TIMER_INSERT: 0
    COUNT_UPDATE: 0
SUM_TIMER_UPDATE: 0
MIN_TIMER_UPDATE: 0
AVG_TIMER_UPDATE: 0
MAX_TIMER_UPDATE: 0
    COUNT_DELETE: 0
SUM_TIMER_DELETE: 0
MIN_TIMER_DELETE: 0
AVG_TIMER_DELETE: 0
MAX_TIMER_DELETE: 0
1 row in set (0.01 sec)

期待通りCOUNT_READは増えましたが(COUNT_STARとか*_WAITはI/Oの合計っぽい)、なぜ2増えたし。内部的には2回インデックスを読み込んでいる?カバリングインデックスになるようにして試してみる。

mysql> SELECT `c2` FROM `t1` WHERE `c2` = 1;
+------+
| c2   |
+------+
|    1 |
+------+
1 row in set (0.00 sec)
mysql> SELECT
    ->     *
    -> FROM
    ->     performance_schema.table_io_waits_summary_by_index_usage
    -> WHERE
    ->     OBJECT_SCHEMA LIKE 'test'
    ->     AND INDEX_NAME LIKE 'c2_idx'\G
*************************** 1. row ***************************
     OBJECT_TYPE: TABLE
   OBJECT_SCHEMA: test
     OBJECT_NAME: t1
      INDEX_NAME: c2_idx
      COUNT_STAR: 4
  SUM_TIMER_WAIT: 28051955
  MIN_TIMER_WAIT: 1154880
  AVG_TIMER_WAIT: 7012688
  MAX_TIMER_WAIT: 15348275
      COUNT_READ: 4
  SUM_TIMER_READ: 28051955
  MIN_TIMER_READ: 1154880
  AVG_TIMER_READ: 7012688
  MAX_TIMER_READ: 15348275
     COUNT_WRITE: 0
 SUM_TIMER_WRITE: 0
 MIN_TIMER_WRITE: 0
 AVG_TIMER_WRITE: 0
 MAX_TIMER_WRITE: 0
     COUNT_FETCH: 4
 SUM_TIMER_FETCH: 28051955
 MIN_TIMER_FETCH: 1154880
 AVG_TIMER_FETCH: 7012688
 MAX_TIMER_FETCH: 15348275
    COUNT_INSERT: 0
SUM_TIMER_INSERT: 0
MIN_TIMER_INSERT: 0
AVG_TIMER_INSERT: 0
MAX_TIMER_INSERT: 0
    COUNT_UPDATE: 0
SUM_TIMER_UPDATE: 0
MIN_TIMER_UPDATE: 0
AVG_TIMER_UPDATE: 0
MAX_TIMER_UPDATE: 0
    COUNT_DELETE: 0
SUM_TIMER_DELETE: 0
MIN_TIMER_DELETE: 0
AVG_TIMER_DELETE: 0
MAX_TIMER_DELETE: 0
1 row in set (0.01 sec)

やっぱり2増えた。。。とりあえずインデックスを使用すると対象の行の値が増えていくことは確認できました。

他のインデックスの行が増えていないことを確認します。

mysql> SELECT
    ->     *
    -> FROM
    ->     performance_schema.table_io_waits_summary_by_index_usage
    -> WHERE
    ->     OBJECT_SCHEMA LIKE 'test'
    ->     AND INDEX_NAME LIKE 'c3_idx'\G
*************************** 1. row ***************************
     OBJECT_TYPE: TABLE
   OBJECT_SCHEMA: test
     OBJECT_NAME: t1
      INDEX_NAME: c3_idx
      COUNT_STAR: 0
  SUM_TIMER_WAIT: 0
  MIN_TIMER_WAIT: 0
  AVG_TIMER_WAIT: 0
  MAX_TIMER_WAIT: 0
      COUNT_READ: 0
  SUM_TIMER_READ: 0
  MIN_TIMER_READ: 0
  AVG_TIMER_READ: 0
  MAX_TIMER_READ: 0
     COUNT_WRITE: 0
 SUM_TIMER_WRITE: 0
 MIN_TIMER_WRITE: 0
 AVG_TIMER_WRITE: 0
 MAX_TIMER_WRITE: 0
     COUNT_FETCH: 0
 SUM_TIMER_FETCH: 0
 MIN_TIMER_FETCH: 0
 AVG_TIMER_FETCH: 0
 MAX_TIMER_FETCH: 0
    COUNT_INSERT: 0
SUM_TIMER_INSERT: 0
MIN_TIMER_INSERT: 0
AVG_TIMER_INSERT: 0
MAX_TIMER_INSERT: 0
    COUNT_UPDATE: 0
SUM_TIMER_UPDATE: 0
MIN_TIMER_UPDATE: 0
AVG_TIMER_UPDATE: 0
MAX_TIMER_UPDATE: 0
    COUNT_DELETE: 0
SUM_TIMER_DELETE: 0
MIN_TIMER_DELETE: 0
AVG_TIMER_DELETE: 0
MAX_TIMER_DELETE: 0
1 row in set (0.00 sec)

インデックスを使わない検索

一応、インデックスを使わない検索も確認してみます。

mysql> SELECT * FROM `t1` WHERE `c4` = 1;
+----+------+------+------+
| c1 | c2   | c3   | c4   |
+----+------+------+------+
|  2 |    1 |    1 |    1 |
+----+------+------+------+
1 row in set (0.00 sec)
mmysql> SELECT
    ->     *
    -> FROM
    ->     performance_schema.table_io_waits_summary_by_index_usage
    -> WHERE
    ->     OBJECT_SCHEMA LIKE 'test'
    ->     AND INDEX_NAME IS NULL\G
*************************** 1. row ***************************
     OBJECT_TYPE: TABLE
   OBJECT_SCHEMA: test
     OBJECT_NAME: t1
      INDEX_NAME: NULL
      COUNT_STAR: 21
  SUM_TIMER_WAIT: 173152201
  MIN_TIMER_WAIT: 43308
  AVG_TIMER_WAIT: 8244961
  MAX_TIMER_WAIT: 80941850
      COUNT_READ: 11
  SUM_TIMER_READ: 14959706
  MIN_TIMER_READ: 43308
  AVG_TIMER_READ: 1359791
  MAX_TIMER_READ: 10818178
     COUNT_WRITE: 10
 SUM_TIMER_WRITE: 158192495
 MIN_TIMER_WRITE: 5541820
 AVG_TIMER_WRITE: 15819049
 MAX_TIMER_WRITE: 80941850
     COUNT_FETCH: 11
 SUM_TIMER_FETCH: 14959706
 MIN_TIMER_FETCH: 43308
 AVG_TIMER_FETCH: 1359791
 MAX_TIMER_FETCH: 10818178
    COUNT_INSERT: 10
SUM_TIMER_INSERT: 158192495
MIN_TIMER_INSERT: 5541820
AVG_TIMER_INSERT: 15819049
MAX_TIMER_INSERT: 80941850
    COUNT_UPDATE: 0
SUM_TIMER_UPDATE: 0
MIN_TIMER_UPDATE: 0
AVG_TIMER_UPDATE: 0
MAX_TIMER_UPDATE: 0
    COUNT_DELETE: 0
SUM_TIMER_DELETE: 0
MIN_TIMER_DELETE: 0
AVG_TIMER_DELETE: 0
MAX_TIMER_DELETE: 0
1 row in set (0.01 sec)

こちらは11増えました。フルテーブルスキャン10行 + 取得結果1行 = 11ってことですかね。まあ、憶測の範囲は出ませんが。

他の行が変更されていないか確認してみます。

mysql> SELECT
    ->     *
    -> FROM
    ->     performance_schema.table_io_waits_summary_by_index_usage
    -> WHERE
    ->     OBJECT_SCHEMA LIKE 'test'
    ->     AND INDEX_NAME LIKE 'c2_idx'\G
*************************** 1. row ***************************
     OBJECT_TYPE: TABLE
   OBJECT_SCHEMA: test
     OBJECT_NAME: t1
      INDEX_NAME: c2_idx
      COUNT_STAR: 4
  SUM_TIMER_WAIT: 28051955
  MIN_TIMER_WAIT: 1154880
  AVG_TIMER_WAIT: 7012688
  MAX_TIMER_WAIT: 15348275
      COUNT_READ: 4
  SUM_TIMER_READ: 28051955
  MIN_TIMER_READ: 1154880
  AVG_TIMER_READ: 7012688
  MAX_TIMER_READ: 15348275
     COUNT_WRITE: 0
 SUM_TIMER_WRITE: 0
 MIN_TIMER_WRITE: 0
 AVG_TIMER_WRITE: 0
 MAX_TIMER_WRITE: 0
     COUNT_FETCH: 4
 SUM_TIMER_FETCH: 28051955
 MIN_TIMER_FETCH: 1154880
 AVG_TIMER_FETCH: 7012688
 MAX_TIMER_FETCH: 15348275
    COUNT_INSERT: 0
SUM_TIMER_INSERT: 0
MIN_TIMER_INSERT: 0
AVG_TIMER_INSERT: 0
MAX_TIMER_INSERT: 0
    COUNT_UPDATE: 0
SUM_TIMER_UPDATE: 0
MIN_TIMER_UPDATE: 0
AVG_TIMER_UPDATE: 0
MAX_TIMER_UPDATE: 0
    COUNT_DELETE: 0
SUM_TIMER_DELETE: 0
MIN_TIMER_DELETE: 0
AVG_TIMER_DELETE: 0
MAX_TIMER_DELETE: 0
1 row in set (0.00 sec)
mysql> SELECT
    ->     *
    -> FROM
    ->     performance_schema.table_io_waits_summary_by_index_usage
    -> WHERE
    ->     OBJECT_SCHEMA LIKE 'test'
    ->     AND INDEX_NAME LIKE 'c3_idx'\G
*************************** 1. row ***************************
     OBJECT_TYPE: TABLE
   OBJECT_SCHEMA: test
     OBJECT_NAME: t1
      INDEX_NAME: c3_idx
      COUNT_STAR: 0
  SUM_TIMER_WAIT: 0
  MIN_TIMER_WAIT: 0
  AVG_TIMER_WAIT: 0
  MAX_TIMER_WAIT: 0
      COUNT_READ: 0
  SUM_TIMER_READ: 0
  MIN_TIMER_READ: 0
  AVG_TIMER_READ: 0
  MAX_TIMER_READ: 0
     COUNT_WRITE: 0
 SUM_TIMER_WRITE: 0
 MIN_TIMER_WRITE: 0
 AVG_TIMER_WRITE: 0
 MAX_TIMER_WRITE: 0
     COUNT_FETCH: 0
 SUM_TIMER_FETCH: 0
 MIN_TIMER_FETCH: 0
 AVG_TIMER_FETCH: 0
 MAX_TIMER_FETCH: 0
    COUNT_INSERT: 0
SUM_TIMER_INSERT: 0
MIN_TIMER_INSERT: 0
AVG_TIMER_INSERT: 0
MAX_TIMER_INSERT: 0
    COUNT_UPDATE: 0
SUM_TIMER_UPDATE: 0
MIN_TIMER_UPDATE: 0
AVG_TIMER_UPDATE: 0
MAX_TIMER_UPDATE: 0
    COUNT_DELETE: 0
SUM_TIMER_DELETE: 0
MIN_TIMER_DELETE: 0
AVG_TIMER_DELETE: 0
MAX_TIMER_DELETE: 0
1 row in set (0.00 sec)

他の行に変更はないようです。

使用されていいないインデックスを確認するには

ということで使用されていないインデックスを調べるSQLは以下のようになるかと思います。

SELECT 
    OBJECT_SCHEMA,
    OBJECT_NAME,
    INDEX_NAME
FROM
    performance_schema.table_io_waits_summary_by_index_usage
WHERE
    OBJECT_SCHEMA LIKE 'データベース名'
    AND INDEX_NAME IS NOT NULL
    AND INDEX_NAME NOT LIKE 'PRIMARY'
    AND COUNT_READ = 0;

今回の検証テーブルでは上記SQLは以下のようになりました。

+---------------+-------------+------------+
| OBJECT_SCHEMA | OBJECT_NAME | INDEX_NAME |
+---------------+-------------+------------+
| test          | t1          | c3_idx     |
+---------------+-------------+------------+

うん、想定通り。

COUNT_*の数の増え方がよくわからなかったですが、インデックスが使用されていなければ増えないようなのでこのSQLである程度特定出来るかと思う。

本番運用しているサーバーとかだと少なからずオーバーヘッドが発生するので”performance_schema = OFF”にしている場合もあるかもしれませんが、ステージング環境や開発環境などでperformance_schemaを有効にして参考にしてみるのもいいかもしれません。データ量とかでオプティマイザが使用するインデックスを変える場合もあるかと思うので、確実に使われてないよって保証は出来ないです。あくまでも参考って感じ。

データ設計上「このインデックス使われていないんじゃない?」っていうのを洗い出して、上記SQLで「ほらやっぱり」っていう。

ちなみに

ちなみに、一応今回の検証にあたってクエリキャッシュが使用されるとカウントアップされないようでしたので、クエリキャッシュを無効にしておきました。

mysql> SET GLOBAL query_cache_size=0;
Query OK, 0 rows affected (0.00 sec)

mysql> SET GLOBAL query_cache_type=0;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW GLOBAL VARIABLES LIKE '%query_cache%';
+------------------------------+---------+
| Variable_name                | Value   |
+------------------------------+---------+
| have_query_cache             | YES     |
| query_cache_limit            | 1048576 |
| query_cache_min_res_unit     | 4096    |
| query_cache_size             | 0       |
| query_cache_type             | OFF     |
| query_cache_wlock_invalidate | OFF     |
+------------------------------+---------+
6 rows in set (0.01 sec)

query_cache_sizeが0、query_cache_typeがOFFになっていればクエリキャッシュは使用されません。

コメントを残す