2019年6月19日(水)に開催いたしました、「初心者による初心者のためのMySQLクエリチューニング勉強会」の資料です。

1. 初心者による初心者のための
クエリチューニング
株式会社セレス 石川 心之介
1

2. 前書き
2

3. 自己紹介
・最近セレスに転職。
・元JavaのSIer。
・MySQL歴＝社歴（６ヶ月）。
・クエリチューニング歴は２ヶ月くらい。。。

4. 弊社について
・株式会社セレス。
・ポイントサイト（モッピー）が主力のWebサービス会社。
・設立１４年目とそこそこの長さ。
4

5. 弊社のシステム構成（モッピーの場合）
・LAMP環境。
・インフラはオンプレ。
・開発も運用も完全自社。
・MySQLを最近8にアップデートした。
5

6. Ｔｗｉｔｔｅｒアカウント
ハッシュタグ
#ceres_tech
#勉強会
#初心者
▼フォローしてね▼
せれすたん

7. 本編
7

8. お品書き
・クエリチューニングとは
・チューニング対象を見つける
・原因を分析する
・解決策を検討する
8

9. クエリチューニングとは
9

10. クエリチューニングとはなんぞや？
・クエリの性能を良くすること。
・良くする＝レスポンス速度をあげる、リソースの使用量を減らす、など。
・チューニング対象を見つける→原因を分析する→解決策を検討する、という流
れで行う。
10

11. クエリチューニングにおける２大巨頭ワード
・インデックス
・実行計画

12. インデックスとは
・特定の値をもつ行を高速に探すための仕組み。
12

13. インデックスについての例え話
・とあるアパートの住人からたなかさんを探す、という状況を想定。
・住人についての情報が何もないと、全ての部屋を確認しないといけない。
・住人の苗字と部屋番号が書かれた名簿があると、名簿を見れば行くべき部屋が
わかる（全ての部屋を確認する必要はない）。

14. インデックスについての例え話
・とあるアパートの住人からたなかさんを探す、という状況を想定。
＝＞SELECT * FROM apartment WHERE last_name = ‘たなか’;
・住人についての情報が何もないと、全ての部屋を確認しないといけない。
＝＞インデックスがない状況。apartmentというテーブルの中身を全て確認しな
いといけない。
・住人の苗字と部屋番号が書かれた名簿があると、名簿を見れば行くべき部屋が
わかる（全ての部屋を確認する必要はない）。
＝＞特定の値（例えでは名字）をもつ行（例えでは部屋番号）を保持するインデ
ックス（例えでは名簿）がある状況。インデックスを見ればapartmentテーブル
の中身を全て見なくても検索できる。

15. 具体的にどんな仕組み？
・Bツリー（バランス木）構造という仕組みでデータを保持することで、効率的
に検索できるようにしている。
15

16. Bツリー構造とは？
・ざっくりこんな感じ。
・一番上をルートノード、一番下をリーフノード、間にあるものをブランチノー
ドと呼ぶ。
・リーフノードは横にも繋がっている。

17. Bツリー構造での検索の流れ
・ノードにある値を小さい順に見て、ノードの値≧検索したい値となった方へ進
む。リーフノードでは一致するものを見つける。

18. インデックスの注意点
・インデックスの向き不向き
・複合インデックス
・インデックスのデメリット
18

19. インデックスの向き不向き
・インデックスに不向きなデータに張っても効果が薄い（むしろ悪いことも）。
・インデックス向きのデータでも、不向きなシチュエーションだと効果が薄い。
・インデックスが使えない構文もある。
19

20. どんなデータに向いてるの？
・ユニークな値が多いデータ。カーディナリティという言葉で表される。
・カーディナリティが高い＝ユニークな値が多い＝効果が高い。
・カーディナリティが低い＝ユニークな値が少ない＝効果が薄い。
20

21. カーディナリティが高い場合
・Bツリーの検索回数が少ないので早い。ユニークなら一発。
21

22. カーディナリティが低い場合
・Bツリーの検索回数が多いので遅い。

23. カーディナリティの例外
・カーディナリティが低くても、分布が偏っていれば効果を出せる。
23

24. 向いてないデータは？
・小規模なデータ。そもインデックスが使用されない可能性が高い。
・nullが多いデータ。インデックスはnullを含まないため。
24

25. どんなシチュエーションだと不向き？
・データの大半を抽出するようなシチュエーション。そもインデックスが使用さ
れなくなる。
・大量のデータから少量を抽出するシチュエーションがインデックス向き。
25

26. インデックスが使えない構文
・前方がワイルドカードのLIKE文
（SELECT * FROM apartment WHERE layout LIKE ‘%LDK’;）
・否定文（SELECT * FROM apartment WHERE floor IS NOT 3;）
・NULLを検索する場合（SELECT * FROM apartment WHERE floor IS NULL;）
・関数を使用した場合
（SELECT * FROM apartment
WHERE date_format(dt_created, ‘%Y%m%d’）> ‘20190601’）

27. 複合インデックス
・複合インデックスとは、複数のカラムの組み合わせに対して張るカラム。
・組み合わせの順序が大事。
27

28. なんで順序が大事なの？
・先頭に指定したカラムは、通常のインデックスとしても使用できるため。
28

29. 複合インデックスのBツリー
・例えばcol1というカラムを先頭に、col2というカラムを２番目に指定して複合
インデックスを作成したとすると以下のようになる。

30. 先頭のカラムで検索した場合

31. ２番目のカラムで検索した場合

32. 複合インデックスの注意点
・データ量の多いテーブルに張るには時間がかかる。
・サービス止める時間が確保できない場合、張れないことも。
32

33. インデックスのデメリット
・登録更新削除の性能が悪くなる。
・登録更新削除をした場合、インデックスの内容を変更しないといけないため。
33

34. インデックスはテーブルとは別の領域で保持
・インデックスのデータ（Bツリー構造で作成されてデータ）は、テーブルとは
別の領域に保持しているので、作成すればするだけDBの容量を食う。

35. 効果的なインデックスだけ張ろう
・効かないインデックスはDBの容量を食うだけ。
・過剰なインデックスは登録更新削除の妨げに。
35

36. 実行計画とは
・クエリを、RDBMSが実行可能な形式に変換したもの。
・クエリは「このテーブルからこの条件で」ということを指定しており、具体的
にどうやって取得するかについては言及していない。
・取得条件に加えて具体的な取得方法について補完したものが実行計画。
・インデックスをどう使用するかについても実行計画を作成する段階で決まる。

37. 実行計画の見本
・実行計画の見方は後ほど。

38. クエリチューニングのアプローチ
・クエリに手を入れるアプローチと、DBに手を入れるアプローチがある。
・クエリ側＝副問い合わせ変えたり。
・DB側＝インデックス張ったり、パーティションを作ったり。
・今回はインデックスを張るところに着目してます。
38

39. クエリチューニングは開発時から
・クエリチューニングは保守作業の文脈で語られることが多いけど、新規開発時
も大事。
・データが取れたらOKではなく、性能を良くできないかも見てみよう。
・テーブルの役割を意識することも大事（定期的に消すデータなのか、残してい
くデータなのかなど）。
39

40. チューニング対象を見つける
40

41. どうやって見つけるの？
・MySQLのスロークエリログ機能を使用する。
41

42. スロークエリログ機能って？
・実行に一定時間以上経過したクエリの情報をログ出力する機能。
・ログ出力先はファイルかDBを選べる。
42

43. ファイルに出すとこんな感じ
43
mysqld, Version: 5.6.44 (MySQL Community Server (GPL)). started with:
Tcp port: 3306 Unix socket: /var/run/mysqld/mysqld.sock
Time Id Command Argument
# Time: 190617 16:36:37
# User@Host: root[root] @ [172.23.0.3] Id: 475
# Query_time: 57.853915 Lock_time: 0.000078 Rows_sent: 1 Rows_examined: 32010240
SET timestamp=1560756997;
SELECT SQL_CALC_FOUND_ROWS * FROM `user` WHERE name = 'test1' LIMIT 1;

44. MySQL付属の解析ツール（ファイル専用）
・mysqldumpslowというコマンドで解析ツールを実行できる。
44
Count: 1 Time=57.85s (57s) Lock=0.00s (0s) Rows=1.0 (1), root[root]@[172.23.0.3]
SELECT SQL_CALC_FOUND_ROWS * FROM `user` WHERE name = 'S' LIMIT N
Count: 1 Time=0.00s (0s) Lock=0.00s (0s) Rows=0.0 (0), 0users@0hosts
mysqld, Version: N.N.N (MySQL Community Server (GPL)). started with:
# Time: N N:N:N
# User@Host: root[root] @ [N.N.N.N] Id: N
# Query_time: N.N Lock_time: N.N Rows_sent: N Rows_examined: N
use test_database;
SET timestamp=N;
SELECT SQL_CALC_FOUND_ROWS * FROM `user` WHERE name = 'S' LIMIT N

45. DBに出すとこんな感じ
45

46. どれくらい時間かかってたらスロークエリなの？
・MySQLの初期設定は10秒以上。
・実際のところはサービス影響の大きさで判断。
・バッチだからある程度時間かかっても良い、トップページなのだから1秒でも
遅い！などなど。
・弊社は2秒で設定しています。
応答を３秒目指した場合、PHP 5~700ms + 通信 300ms + DB 2000ms = 3000ms
46

47. スロークエリログ機能の設定方法
・MySQLのグローバル変数に設定する。
・スロークエリログ機能のオンオフ：slow_query_log
・ログ出力先：log_output
・スロークエリと判定する秒数：long_query_time
・見るならSHOWコマンドを使用する。
SHOW VARIABLES LIKE = '%slow_query%';
・変えるならSETコマンドを使用する。
SET GLOBAL slow_query_log = 'ON';
47

48. 原因を分析する
48

49. どうやって分析するの？
・実行計画を見る。
・実行計画はEXPLAINという構文を使用することで見ることができる。
・EXPLAINの使い方は、実行計画を見たいクエリの前につけるだけ。
・本番相当のデータで行わないと正確な実行計画が出ないので注意。
49

50. EXPLAINの出力
・実行計画が表形式で出力されます。

51. 実行計画の見方
・今回はインデックスに関する初歩的な分析について説明。
・なので全てのカラムは見ない。
・見るのはtype、possible_keys、Keyの３つ。

52. 実行計画におけるtypeとは？
・インデックスの使用方法を示す。
・今回着目するのはALLとindexの２つ。
ALL インデックスを使用しておらず、テーブルの中身を全て見る。
index インデックスの中身を全て見る。
range 範囲検索する。
ref 特定のユニークではない値を検索する。
eq_ref 別のテーブルを含めて特定のユニークな値を検索する。
const 特定のユニークな値を検索する。

53. 実行計画におけるpossible_keysとは
・使用可能なインデックスを示す。
・複数使用可能なインデックスがある場合は、全て記載される。
・PRIMARYというインデックスはPKに対して自動で作成されたインデックス。
・NULLの場合は使用可能なインデックスがないことを示す。

54. 実行計画におけるKeyとは
・実際に使用するインデックスを示す。
・NULLの場合はインデックスを使用しないことを示す。

55. どういった分析をすれば良いの？
・使用可能なインデックスはあるか。
・使用されている場合、効果的に使用されているか。
55

56. 使用可能なインデックスがあるかの判断方法
・typeがALL、possible_keysとKeyがnullの場合、そのクエリに使用できるインデ
ックスがない。

57. 効果的に使用されているかの判断方法
・typeを見る。typeがindexの場合、インデックスを使用したフルテーブルスキャ
ンを行なっているため、indexの効果を発揮しきれていない。

58. 解決策を検討する
58

59. 使用可能なインデックスがなかった場合
・当該カラムにインデックスが張られていなければ、インデックスの新規作成を
検討する。
・当該カラムが含まれた複合インデックスがある場合、複合インデックスを使用
できるようにクエリを変えることを検討する。

60. インデックス張ってない事なんて実務であるの？
・なんだかんだある。。。
・例えば、ログテーブルを使用して売上レポートを作成しようとした時。
・ログテーブルとして作っていたのでPK以外作成しておらず、日付とかユーザー
IDとかで検索しようとしたらとても遅かった。

61. 【再掲】クエリチューニングは開発時から
・クエリチューニングは保守作業の文脈で語られることが多いけど、新規開発時
も大事。
・データが取れたらOKではなく、性能を良くできないかも見てみよう。
・テーブルの役割を意識することも大事（定期的に消すデータなのか、残してい
くデータなのかなど）。
61

62. インデックスを使用しているけど効果的でない場合
・検索条件の変更を検討する。

63. 例えば弊社の事例
・BEFORE
・AFTER
SELECT DISTINCT id FROM person
WHERE parent <> 0
AND dt_created >= '2018-12-20 23:40:02';
SELECT DISTINCT id FROM person
WHERE parent <> 0
AND id >= (SELECT id FROM person WHERE dt_created >= '2018-12-20
23:40:02' ORDER BY id LIMIT 1);

64. 実行計画的にはこう変わった
・BEFORE
・AFTER
・インデックススキャンから範囲検索に。
・副問い合わせ部分はインデックススキャンだが取得レコード数が少ない。

65. 具体的には
・キーを張っていないdt_createdで範囲検索を行なっていた部分を、主キーであ
るidで範囲検索するよう変更した。
・dt_createdによる検索は行なっているものの、１件しか取得しないようにして
いる（LIMIT 1）ので、速度は速い。
・idの並び順とdt_createdの並び順が同等であるためこういったことができた。

66. まとめ
・クエリチューニングは開発時から意識。
・スロークエリログを見る。
・実行計画からインデックスが効いているかを分析。
・インデックスの向き不向きを踏まえて効果的なインデックスだけ張る。
66