パフォーマンスとIN句とAND、実行速度について

質問

mysqlのMyISAM型でこういったデータの取得は適切なやり方でしょうか。
・件数は700前後
・インデックスは主キー以外に使っていません
・トランザクションや外部キーも使っていません

SELECT * FROM tabledate WHERE 100<a AND 200>a AND 300<b AND 1000>b AND c='てすと' AND d='テテテ' AND e='testtest' AND f='ttt' AND g IN('123','456','789','122','333','4566','888') AND h IN('666','777') AND ・・・ANDが１０個続く・・・ ORDER BY year_manth_day DESC

コマンドプロンプトで実行すると結果は0.12secでした。
自分のパソコンの中だけで動かしているのですが、
この実行時間は充分でしょうか。

回答No.4

hogya · ベストアンサー

ALLの意味はインデックスをつけないといけないということではなくて、オプティマイザがフルテーブルスキャンをしたほうが効率的と判断したということですね。
例えインデックスがあってもフルテーブルスキャンをしたほうが効率的と判断されれば使われません。
また、possible_keysは今回の条件で使えるインデックスがなかったよ、という意味です。（WHERE句で指定していて、レコードの大部分が絞りこめるような列にインデックスを貼って試してみましたか？）
それと、Extraにfilesortが出ていますが、検索よりもソートの負荷の方が高いかもですよ。ケースによってはORDERBYを外してプログラムで処理した方が速いケースもあります。
（今回の場合は件数が少ないので大した違いはないでしょうが。）

しかし、データが最大で数百件程度ならな、それほどムキになって現在の実行時間を短縮する意味もないような気がします。
（現在の時間が半分になったとしても体感ではわからないレベルでしょう）

お礼

とても参考になりました。
有難うございました。

回答No.3

yambejp

#1です

上限がきまっていて、負荷テスト段階で満足しているなら
とくに気にする必要はないでしょう。

2回目、3回目はキャッシュされているでしょうからあまり意味がないです
（普通に考えて何度も同じ条件で検索をかけることはないでしょうから）

お礼

とても参考になりました。
有難うございました。

回答No.2

hogya

定石ですがとりあえず、EXPLAINコマンドでオプティマイザがどういう順序でSQLを発行しているのか実行計画を見てみましょう。
その上でマニュアル上に書いてあるポイントで最適化を施せばとりあえず基準となるパフォーマンスのデータがとれるかと思います。下記リンクの特に「SELECTクエリーの速度」や「WHERE 節最適化」、「クエリパフォーマンスの推定」などの章を読んでみてください。
その上でまだコストがかかるようであれば、そのコストの掛かる部分について対応策を考えるのがよいかと思います。

SELECTおよびその他のステートメントの最適化
http://dev.mysql.com/doc/refman/5.1-olh/ja/query-speed.html

また、MySQL 5.6.3からは「Optimizer Tracing」というオプティマイザがどのような判断をしたかということが、トレースできる機能があるようです。
（実際に使ったことはありませんが）

お礼

実際のところ500いくかどうかだと思います。いっても700までです。早ければ今のままでいいかも。なので、まずないですが、もしそれ以上になりパフォーマンスに問題が出ればそのときに対処すればいいかと思っていました。速ければ負荷に問題がないですか？

1回目は2 rows in set (0.09 sec)
2回目以降は2 rows in set (0.01 sec)
でした。

EXPLAIN EXTENDEDで見てみると

+----+-------------+--------+------+---------------+------+---------+------+----
--+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+------+---------------+------+---------+------+----
--+-----------------------------+
| 1 | SIMPLE | tabledate | ALL | NULL | NULL | NULL | NULL | 500 | Using where; Using filesort |
+----+-------------+--------+------+---------------+------+---------+------+----
--+-----------------------------+

ALLはインデックスをつけないといけないといことみたいで、
possible_keysでインデックスを指定すべきフィールドが分かるそうですが、
NULLになってしまいます。

回答No.1

yambejp

＞SELECT *

してる時点で、スピードに文句を言ってはいけません。
個人的な感想ですが、700件のデータで0.12秒もかかっていては
データ件数が増えたら使い物にならないと思います。

適当なインデックスを貼り、インデックスに基づいたフィールドのみ
表示する必要がありそうです

お礼

実際のところ500いくかどうかだと思います。いっても700までです。早ければ今のままでいいかも。なので、まずないですが、もしそれ以上になりパフォーマンスに問題が出ればそのときに対処すればいいかと思っていました。速ければ負荷に問題がないですか？

1回目は2 rows in set (0.09 sec)
2回目以降は2 rows in set (0.01 sec)
でした。

EXPLAIN EXTENDEDで見てみると

+----+-------------+--------+------+---------------+------+---------+------+----
--+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+--------+------+---------------+------+---------+------+----
--+-----------------------------+
| 1 | SIMPLE | tabledate | ALL | NULL | NULL | NULL | NULL | 500 | Using where; Using filesort |
+----+-------------+--------+------+---------------+------+---------+------+----
--+-----------------------------+

ALLはインデックスをつけないといけないといことみたいで、
possible_keysでインデックスを指定すべきフィールドが分かるそうですが、
NULLになってしまいます。