2016/11/07mysqlのチューニングをしていて、どうしてもインデックスが、どの指定の時に何が使われるのかが分からなかったので整理。(`member`,`visit`,`page_view`,`date`))100万件ぐらいデータをぶち込む。今回は、memberpagedateの3項目について検索するので、それらにインデックスを張る。一つずつ、二つずつ、三つずつ、で順番も代えて以下のとおり。idx_page_date_member(page(255),date,member);※pageはtext型なので、前方255byteまでしかindexがはれない。BYを利用したときと、そうでないとき、どのインデックスが使われるか確認。「Whereの条件順とindexのkeyの順が一致していれば、それが使われる」らしい。取得項目とかいろいろ絡んでいるようだが、ひとまず検証。'test_user'利用インデックス:memberここはイメージどおり。pageの場合だけ複合インデックスが利用されているのは、なぜじゃろう。'2015-10-10';⇒利用インデックス:member中間まとめ思っていたのと正直全然違う。複数項目で条件指定しても、複合インデックスを使ってくれない。使わない方が早いという算段なのか。トータル件数やカーディナリティの問題だろうか。なんかindexに対する理解が違うのだろう。条件のマッチ率が高すぎると、インデックスが使われずフルスキャンになるとのこと。欲しいデータ次第ではあるのだけれど、、、一応確認。いうときは条件をつけない方がマシということなのだろうか。'/%'利用インデックス:idx_page_memberお、使われる。LIKE条件が%になるからと言って、むりやり検索対象項目を外すとかはしなくて良さそうだと。Byで指定した項目でインデックスが利用される。date利用インデックス:idx_member_dateを、初めてmember_dateが使われた。memberidx_date_memberが使われた。ここはイメージどおりだ。1項目足すと、インデックスが使われなくなった。filesort」も発生。BYのキーどちらがインデックス上先にあるべきかという事が確認できたか。member;利用インデックス:idx_page_memberdateが外れて、pageとmemberで。pageとdateの順番代えても同じ...まとめ正直今回の確認では、まとまらなかった。「whereの順番とindexの順番をそろえれば、インデックスが使われる。」とういのは浅すぎる考え方の模様。インデックスの使われ方を調べてみる必要あり。