質問: t.tag_id AND t.tag ='タグ50001'; 10000 rows in set (0.01 sec) のような状況です。 MySQLは5.6です。 物理的なデータファイルも同じものを参照しているはずなので、ディスクのキャッシュなどでもないかと考えているのですが、(再起動後などに)事前に何かクエリを発行してキャッシュを持ったり、バージョンアップなども含めて解決ができればと考えています。
回答: 2回目が早いのは1回目の結果を利用しているからです。 DBMSも、遅いならまだしも、早くて文句を言われる筋合いはないですし。 ※追記 8.9.3.2 クエリーキャッシュ SELECT オプション そもそも**SQL_NO_CACHE**の意図を取り違えています。 **SQL_NO_CACHE**はキャッシュの更新をしないという意味で、クエリーキャッシュを無効にするには、query_cache_size システム変数を 0 に設定することです。 解決すべきは1回目に遅い事で、これはチューニングするしかありません。 先ずは、実行計画の内容を確認しましょう。 実行結果からはインデックスは最低あるような気もしますので、以下のようなSQLに変更すると改善されるかもしれません。 ``` -- 1 SELECT id FROM tagmap where tag_id in (select tag_id from tag where tag ='タグ10001') -- 2 SELECT mp.id FROM tagmap mp inner join tag tg on mp.tag_id=tg.tag_id where tg.tag ='タグ10001' ``` 質問では1万件ですが、実際にどの程度に絞り込まれるかによりますが、件数次第では必要なインデックスも変わってくると思います。