下記のようなテーブルのインデックスはどう作成するのが最も速いでしょうか。
startとendの範囲からhogeを取得するのが目的で800万レコードほどです。
innodb
+----------+----------+--------+
| start | end | hoge |
+----------+----------+--------+
| 10000 | 11000 | test |
| 11001 | 13000 | sample |
| 15000 | 16000 | dummy |
+----------+----------+--------+
+----------+---------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+---------------+------+-----+---------+-------+
| start | decimal(10,0) | NO | | NULL | |
| end | decimal(10,0) | NO | | NULL | |
| hoge | varchar(128) | NO | | NULL | |
+----------+---------------+------+-----+---------+-------+SELECT * FROM sample WHERE end >= 12345 AND start <= 12345
# => sampleEXPLAINを使い、いろいろ試したのですが、
だいたい以下のようなスコアでした。
インデックスなし・・・10s
startにPRIMARY・・・5s
start、end複合INDEX・・・5s
endにINDEX・・・2s
2s以上あがらないのはスペックや設定の問題でしょうか。
（innodbバッファプールなどは初期設定だったかと思います。
アドバイスいただけますでしょうか。
よろしくお願いいたします。
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
+2
以下2通りを試してみてください。
end、startという順番の複合インデックス
startにPRIMARY・・・5s
endにINDEX・・・2s
という結果からendの方がカーディナリティが高いようなので、そちらを先にスキャンさせてみる。
startとendそれぞれに単一カラムインデックス
インデックスマージが効くかもしれないので。
https://dev.mysql.com/doc/refman/5.6/ja/index-merge-optimization.html
インデックスの追加だけでは望むパフォーマンスが得られない場合、スペックや設定の見直しに加えてテーブルのパーティション化も検討してみてください。
https://dev.mysql.com/doc/refman/5.6/ja/partitioning.html
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+1
実行に2s必要になるのは抽出行数が多いためではないでしょうか？
コストの殆どをメモリの確保やデータ構築、転送に使っているのでは？と推測します。
次のSQLなら早いのではないかと思います。
SELECT count(*) FROM sample WHERE end >= 12345 AND start <= 12345
とか
SELECT * FROM sample WHERE end <= 1 AND start <= 0INDEX(ソート済み）で何が早いかというと、未ソートなら800万行1つ1つに対してend<=12345を(つまり800万回)チェックしないといけないのに対して、ソート済みなら境界値を探して、それ以下を全て取得すればいいからです。
確認処理 × 800万回 + 抽出処理 × 抽出行数 VS 確認処理 × 最大21回 + 抽出処理 × 抽出行数
※実際は未ソートでもソートしてから境界値を探すほうが早いのでそちらが実施されると思います。
INDEXが片方にしかない場合（複合INDEXでも同じ）、有るほうの抽出は早いでしょうが、無い側の速度は一つ目の条件で絞り込まれた行数に依存します。
また仮に両方に有っても、一つ目の条件で抽出されたグループに対して二つ目のINDEXは使えないか、使えても効果が薄くなると予想できます。
恐らくstartとendに個別にINDEXを作成するのが最速だと思います(オプティマイザが抽出行数が少ないほうを最初に実行するように選んでくれると思います）が、2sより劇的に早くなるかはやってみないとわかりません。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう！
- ただいまの回答率 88.37%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる