![重いSQLの洗い出し方 STEP1
スロークエリーログに全SQLを記録
$ sudo rm mysqld-slow.log
$ mysql –u user_name –p
mysql> SET GLOBAL long_query_time = 0;
mysql> SET GLOBAL log_slow_verbosity=full;
mysql> FLUSH LOGS;
# User@Host: user[user] @ [1.2.3.4]
# Query_time: 0.067361 Lock_time: 0.000030 Rows_sent: 16 Rows_examined: 121031
SET timestamp=1346772142;
SELECT zpam.zip_cd
FROM zip_area_mast zpam
WHERE zpam.point_cd = 11276 AND zpam.del_flag = 0;
:
実行時間
テーブルロックした時間
行ロックした時間はカウン
トされていので注意！
結果の行数
スキャンした行数](https://image.slidesharecdn.com/mysqlsqltuningseminormynajpug201602-160222054211/85/MySQL-23-320.jpg)
![【7.テーブルの削除】
• TRUNCATE = DROP + CREATE
• 注意：AUTO_INCREMENTがリセット
• 条件を指定したい
• パーティション化 ＋ [DROP|TRUNCATE] PARTITION
DELETE FROM push_message；
TRUNCATE TABLE push_message ；
Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止](https://image.slidesharecdn.com/mysqlsqltuningseminormynajpug201602-160222054211/85/MySQL-58-320.jpg)
Ad
More Related Content
What's hot (20)
Viewers also liked (8)
Ad
Similar to ヤフー社内でやってるMySQLチューニングセミナー大公開 (20)
Ad
More from Yahoo!デベロッパーネットワーク (20)
ヤフー社内でやってるMySQLチューニングセミナー大公開
- 1. ヤフー社内でやってる MySQLチューニングセミナー 大公開 2016/02/20 MyNA , JPUG 合同勉強会
- 3. Yahoo! JAPANのRDB環境 • 11g RAC Enterprise Edition • 約200DB • サーバ 200台, Exadata もあるよ • MySQL 5.1 (RR,Mixed) Percona 5.5 (RR,Mixed) Percona 5.6 (RC,RBR,GTID) • 約500DB • サーバ 300台 Oracle Database MySQL Percona
- 4. 4
- 5. 自己紹介 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 5 • 三谷 智史（@mita2） • 所属 DBMS技術 RDB専門部隊 13名 • DB Administration 黒帯
- 6. DBAあるある • へんなクエリ流されて、負荷が爆発 • SQLがスパゲッティすぎて解読不能 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 6 RDBを正しく使ってもらうために、 社内でセミナーを実施しています。
- 7. ヤフー社内でやってる MySQLチューニングセミナー大公開 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 7
- 8. ご注意 • 個人の経験をもとに記載しています。間違った情報が含ま れてたりするかもしれません。 • Version 5.5 を前提に記載しております。最新のバージョ ンでは改善されているケースもあります。 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 8
- 9. 本日の流れ 1. インデックスについて 2. SQLチューニング手順 1. 重いクエリの洗い出し 2. 実行計画の確認 3. SQLチューニング例 ※ InnoDBを前提。MyISAMはもう卒業しましょう。 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 10. インデックスについて
- 11. • インデックスはツリー構造 • データはソートされている • リーフノードに値と行のPKを格納 なぜ、インデックスで高速化するのか？ PK col1 time 1 a 11:15 2 f 01:10 3 d 03:01 ： ： ： SELECT * FROM t WHERE col1 = ‘f’ インデックス対象 a-p r-z a pk=1 d pk=3 f pk=2 p pk=9 r pk=4 t pk=5
- 12. カーディナリティ mysql> show index from t; +-----+----------+----------+------------+-<SNIP>-+-----------+-------------+ |Table|Non_unique| Key_name |Seq_in_index| | Collation | Cardinality | +-----+----------+----------+------------+--------+-----------+-------------+ | t | 0| PRIMARY | 1| | A | 5 | +-----+----------+----------+------------+--------+-----------+-------------+ 1 row in set (0.00 sec) インデックス内のユニークな値 の多さを表した指数 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 13. カーディナリティとは • カーディナリティが低いと効果が少ない • カーディナリティが高いデータの例 • AUTO_INCREMENT、住所、更新日時 • カーディナリティが低いデータの例 • フラグ、カテゴリ、都道府県 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 14. なぜ効果が少ないのか？ 0 pk=1 pk=3 pk=5 ： ： ： 1 pk=2 pk=4 pk=6 ： ： ： PK is_pk_even_num （PKが偶数か？） time 1 0 11:15 2 1 12:31 3 0 13:44 4 1 14:01 ： ： ： 1000000 1 20:01 SELECT * FROM t WHERE is_pk_even_num = 1 AND time <= 12:00 • 半分までしか絞り込めない • インデックスを経由することによる オーバーヘッドが無視できない インデックス対象 × 50万回
- 15. PK is_pk_1000multi (PKが1000の倍数?) time 1 0 11:15 ： 0 12:31 1000 1 13:44 ： ： 14:01 ： ： ： 1000000 1 20:01 例外 0 pk=1 pk=2 pk=3 ： ： ： 1 pk=1000 pk=2000 pk=3000 ： SELECT * FROM t WHERE is_pk_1000multi = 1 AND time <= 12:00 • 分布が偏っていれば効果が大きくなる • 条件によって効果が異なる インデックス対象 × 1000回 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 16. Left-Most-Index 以下のインデックスは同じ？ 違います インデックスA. CREATE INDEX idxA1 ON mytable (col1); CREATE INDEX idxA2 ON mytable (col2); インデックスB. CREATE INDEX idxB1 ON mytable (col1, col2); インデックスC. CREATE INDEX idxC1 ON mytable (col2, col1); Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 17. 複合インデックスでは指定順が重要 a pk=1 9 a pk=2 8 b pk=3 7 b pk=4 6 5 pk=1 c 6 pk=4 b 7 pk=2 b 8 pk=3 a インデックスB. CREATE INDEX idxB1 ON mytable (col1, col2); インデックスC. CREATE INDEX idxC1 ON mytable (col2, col1); a b～c 5～6 7～9 col2col1 col1col2 c pk=5 5 9 pk=5 a
- 18. 複合インデックスでは指定順が重要 絞り込み対象カラム → 1.WHRER col1 = ‘x’ 2.WHERE col2 = ‘x’ 3.WHERE col1 = ‘x’ AND col2 = ‘x’ インデックスA idxA1 が利用される idxA2 が利用される idxA1, idxA2 どちらかが利用される。 ※ インデックスB idxB1 が利用される インデックスは利 用されない idxB1 が利用される。 idxA1, idxA2より高速。 インデックスC インデックスは利 用されない idxC1 が利用される idxC1が利用される。 idxA1, idxA2より高速。 ※ 場合によってはインデックスマージ インデックスA. CREATE INDEX idxA1 ON mytable (col1); CREATE INDEX idxA2 ON mytable (col2); インデックスB. CREATE INDEX idxB1 ON mytable (col1, col2); インデックスC. CREATE INDEX idxC1 ON mytable (col2, col1);
- 19. インデックスを貼るときのポイント • カーディナリティの高いカラムを選ぶ • 複合インデックスのカラムの順に注意 • 更新性能・キャッシュ効率が低下するため、 必要なものだけに貼る Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 20. SQLチューニング手順
- 21. SQLチューニングの手順 1. 重いクエリランキングを出す 2. 実行計画を確認する 3. チューニング 1. SQLの書き換え 2. インデックスを貼る 3. テーブル構成をみなおす etc Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 22. SQLチューニングの手順 1. 重いクエリランキングを出す 2. 実行計画を確認する 3. チューニング 1. SQLの書き換え 2. インデックスを貼る 3. テーブル構成をみなおす etc Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 23. 重いSQLの洗い出し方 STEP1 スロークエリーログに全SQLを記録 $ sudo rm mysqld-slow.log $ mysql –u user_name –p mysql> SET GLOBAL long_query_time = 0; mysql> SET GLOBAL log_slow_verbosity=full; mysql> FLUSH LOGS; # User@Host: user[user] @ [1.2.3.4] # Query_time: 0.067361 Lock_time: 0.000030 Rows_sent: 16 Rows_examined: 121031 SET timestamp=1346772142; SELECT zpam.zip_cd FROM zip_area_mast zpam WHERE zpam.point_cd = 11276 AND zpam.del_flag = 0; : 実行時間 テーブルロックした時間 行ロックした時間はカウン トされていので注意！ 結果の行数 スキャンした行数
- 24. • Percona Tookit の pt-query-digest で集計 重いSQLの洗い出し方 STEP2 $ sudo pt-query-digest --group-by fingerprint¥ --order-by Query_time:sum ¥ --since '2015-06-14 00:00:00' --until '2015-06-14 23:59:59' ¥ mysqld-slow.log 合計実行時間でソート オプション ソート条件 Query_time:avg 平均実行時間 Query_time:sum 合計実行時間 InnoDB_IO_r_bytes:sum バッファプールにヒットせず、DISKから読み取った データ量 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 25. 集計結果 # Query 5: 39.92 QPS, 229.19kx concurrency, ID 0x72BFE142E32896BD at byte 88442 # Time range: 2015-10-29 23:00:00 to 23:59:59 # Attribute pct total min max avg 95% stddev median # ============ === ======= ======= ======= ======= ======= ======= ======= # Count 31 143676 # Exec time 11 660s 150us 623ms 5ms 18ms 10ms 490us # Lock time 20 13s 32us 5ms 91us 113us 30us 89us # Rows sent 0 264.02k 0 4 1.88 2.90 0.69 1.96 # Rows examine 0 264.02k 0 4 1.88 2.90 0.69 1.96 # Rows affecte 0 0 0 0 0 0 0 0 # Rows read 0 264.02k 0 4 1.88 2.90 0.69 1.96 # Bytes sent 0 16.80M 83 171 122.61 143.84 17.33 124.25 # Merge passes 0 0 0 0 0 0 0 0 # Tmp tables 0 0 0 0 0 0 0 0 # Tmp disk tbl 0 0 0 0 0 0 0 0 # Tmp tbl size 0 0 0 0 0 0 0 0 # Query size 18 26.14M 148 271 190.81 246.02 51.01 143.84 # InnoDB: # IO r bytes 9 786.66M 0 80.00k 5.61k 15.96k 9.17k 0 # IO r ops 9 49.17k 0 5 0.35 0.99 0.57 0 # IO r wait 14 569s 0 620ms 4ms 17ms 10ms 0 ＜省略＞ SELECT topic_id FROM weather WHERE (consumeruri = ‘abc') AND (consumeruri_type = 'android')¥G 合計実行回数 平均実行時間 （1クエリあたり） レスポンス行数（1クエリあたり） クエリ 処理過程で読み込んだ行数 （1クエリあたり） キャッシュヒットせずに DISKから読んだバイト数
- 26. SQLチューニングの手順 1. 重いクエリランキングを出す 2. 実行計画を確認する 3. チューニング 1. SQLの書き換え 2. インデックスを貼る 3. テーブル構成をみなおす etc Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 27. 実行計画の確認 • 実行計画＝クエリの処理の流れ • 「EXPLAIN」をクエリの先頭に付ける • 更新系クエリはSELECTに書き換え UPDATE t SET col = newvalue WHERE condition = ‘x’; EXPLAIN SELECT col FROM t WHERE condition = ‘x’; Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 28. EXPLAINの結果の例 mysql> EXPLAIN SELECT t1.pk, t1.col1, t2.col2 FROM t1 INNER JOIN t2 ON (t1.pk = t2.fk) WHERE t1.pk = 1; +----+------------+------+------+--------------------+--------+--------+------+-----+-------------+ | id | select_type| table| type | possible_keys | key | key_len| ref | rows| Extra | +----+------------+------+------+--------------------+--------+--------+------+-----+-------------+ | 1 | SIMPLE | t1 | const| PRIMARY,pk_col1_idx| PRIMARY| 4 | const| 1| | | 1 | SIMPLE | t2 | ALL | NULL | NULL | NULL | NULL | 5| Using where | +----+------------+------+------+--------------------+--------+--------+------+-----+-------------+ カラム 説明 id SELECTごとに振られるID。処理順ではない点に注意。 select_type SELECTの種類。SIMPLE, SUBQUERY, UNIONなど。 type テーブルへのアクセス方法。インデックスの利用有無、読取範囲などがわかる。 possible_keys 利用可能なインデックス。 key 実際に利用されたインデックス。possible_keys からインデックスの内容や統計情報を加味して、選択さ れたインデックス。 key_len 読み取ったインデックスのバイト数。 ref 比較するカラム。constの場合は定数（WHERE x = 1のような場合）。 rows スキャンする見積もり行数。JOINやサブクエリが関係する場合は外部表のrows × 内部表のrowsがス キャンする行になる。 Extra その他の情報
- 29. SQLチューニングの手順 1. 重いクエリランキングを出す 2. 実行計画を確認する 3. チューニング 1. SQLの書き換え 2. インデックスを貼る 3. テーブル構成をみなおす etc Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 30. チューニング例
- 31. 代表的なチューニング例 1. type=ALL または type=index で rows が大きい 2. Extra に Using temporary; Using filesort でrowsが大きい 3. select_type が DEPENDENT SUBQUERY 4. JOINにおいて2つ目以降のExtraにUsing whereが出力さてい て rows が大きい 5. 大量更新 6. データ削除 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 32. 代表的なチューニング例 1. type=ALL または type=index で rows が大きい 2. Extra に Using temporary; Using filesort でrowsが大きい 3. select_type が DEPENDENT SUBQUERY 4. JOINにおいて2つ目以降のExtraにUsing whereが出力さてい て rows が大きい 5. 大量更新 6. データ削除 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 33. 【1.フルスキャン】 TYPE=ALL mysql> EXPLAIN SELECT push_id FROM push_info WHERE deleted=1 AND datediff(now(), mod_date) > '180'; +--+-----------+---------+----+-------------+----+-------+----+-------+--------------------------+ |id|select_type|table |type|possible_keys|key |key_len|ref |rows |Extra | +--+-----------+---------+----+-------------+----+-------+----+-------+--------------------------+ |1 |SIMPLE |push_info|ALL |NULL |NULL|NULL |NULL|1115182|Using where; | +--+-----------+---------+----+-------------+----+-------+----+-------+--------------------------+ mysql> SHOW INDEX FROM push_info; +-----------+------------+--------------------+--+----------+--------+------+------------+ | Table | Non_unique | Key_name |～| Sub_part | Packed | Null | Index_type | +-----------+------------+--------------------+--+----------+--------+------+------------+ | push_info | 0 | PRIMARY |～| NULL | NULL | | BTREE | +-----------+------------+--------------------+--+----------+--------+------+------------+ • mod_dateとdeletedにインデックスを貼るべき • 関数を適用した場合インデックスは効かない • すべての行に対してdatediffを実行してるのも× • mod_date < date_sub(NOW(), INTERVAL 180 DAY) と書くべき 全部読み込み 行数多い 111万行に対し て絞り込み
- 34. インデックスが効かない条件 Extra 関数 WHERE datediff(now(), mod_date) > '180' 式 WHERE col1 / 2 = 0 否定構文 WHERE col1 != 3 LIKE検索 ※ 前方一致除く WHERE col1 LIKE ‘%string%’ WHERE col1 LIKE ‘%string’ Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 35. 【1.フルスキャン】チューニング結果 mysql> CREATE INDEX idx01 ON push_info(deleted, mod_date); mysql> EXPLAIN SELECT push_id FROM push_info WHERE deleted=1 AND mod_date < date_sub(NOW(), INTERVAL 180 DAY); +----+-------------+-----------+-------+-------+------+------+--------------------------+ | id | select_type | table | type | key | ref | rows | Extra | +----+-------------+-----------+-------+-------+------+------+--------------------------+ | 1 | SIMPLE | push_info | range | idx01 | NULL | 10 | Using index | +----+-------------+-----------+-------+-------+------+------+--------------------------+ インデックスの 範囲読み込み 行数が10行 インデックスだ けで解決でき るクエリ • Before: 380msec → After: 0msec Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 36. 代表的なチューニング例 1. type=ALL または type=index で rows が大きい 2. Extra に Using temporary; Using filesort でrowsが大きい 3. select_type が DEPENDENT SUBQUERY 4. JOINにおいて2つ目以降のExtraにUsing whereが出力さていて rows が大きい 5. 大量更新 6. データ削除 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 37. 【2.ソート】 mysql> EXPLAIN SELECT order_time,seller_id,image_id,item_id,＜省略＞ FROM order_master WHERE is_hidden_page = '0' ORDER BY order_time DESC LIMIT 20; +--+-----------+--------------+----+---------------+----+----------+-----------------------------+ |id|select_type| table |type| possible_keys |key | rows | Extra | +--+-----------+--------------+----+---------------+----+----------+-----------------------------+ | 1|SIMPLE | order_master |ALL | NULL |NULL| 12200494 | Using where; Using filesort | +--+-----------+--------------+----+---------------+----+----------+-----------------------------+ • is_hidden_page は殆どの行で0 • カーディナリティが低いため× • ソートにインデックスは有効か？ • LIMIT句がある場合に効果が高い 1200万件 ソートしている Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 38. 【2.ソート】チューニング結果 mysql> CREATE INDEX OM_OTM ON order_master (order_time); mysql> EXPLAIN SELECT order_time,seller_id,image_id,item_id,＜省略＞ FROM order_master WHERE is_hidden_page = '0' ORDER BY order_time DESC LIMIT 20; +--+-------------+--------------+-----+---------------+--------+------+-------------+ |id| select_type | table |type | possible_keys | key | rows | Extra | +--+-------------+--------------+-----+---------------+--------+------+-------------+ | 1| SIMPLE | order_master |index| NULL | OM_OTM | 20 | Using where | +--+-------------+--------------+-----+---------------+--------+------+-------------+ 20個だけ取る • インデックスはソート済みのため、ソートが不要 • 上位20件だけ取ったら、処理を終了 • Before: 4300sec → After: 0sec ソートがなくなるインデックス利用 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 39. 【2.ソート】 CALC_FOUND_ROWSはNG • SQL_CALC_FOUND_ROWS句 • 条件にマッチしたレコードが全部で何件あったかを返す • LIMIT句と一緒に使う • 「全部で何件」＝ LIMIT句がないのと同じ Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 40. 【2.ソート】 考慮事項 • 1度に使われるインデックスは、 各テーブルにつき１つ • 選択が必要 • ソートを最適化する • 絞り込み（WHERE句）を最適化する Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 41. 代表的なチューニング例 1. type=ALL または type=index で rows が大きい 2. Extra に Using temporary; Using filesort でrowsが大きい 3. select_type が DEPENDENT SUBQUERY 4. JOINにおいて2つ目以降のExtraにUsing whereが出力さていて rows が大きい 5. 大量更新 6. データ削除 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 42. 【3.相関サブクエリ】 mysql> EXPLAIN SELECT team_name FROM team WHERE team_id IN (SELECT team_id FROM member WHERE skill IN ("C")); +----+--------------------+--------+------+---------------+省略+------+-------------+ | id | select_type | table | type | possible_keys | | rows | Extra | +----+--------------------+--------+------+---------------+----+------+-------------+ | 1 | PRIMARY | team | ALL | NULL | | 3 | Using where | | 2 | DEPENDENT SUBQUERY | member | ALL | NULL | | 5 | Using where | +----+--------------------+--------+------+---------------+----+------+-------------+ team_id team_name 1 Team1 2 Team2 3 Team3 team_id member_name skill 1 Yahoo Taro C 1 Yahoo Jiro Python 2 Yahoo Hanako Ruby 2 Yahoo Saburo PHP 3 Yahoo Sirou Perl ■ member■ team Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 43. 【3.相関サブクエリ】 期待する動作 team_id team_name 1 Team1 2 Team2 3 Team3 team_id member_name skill 1 Yahoo Taro C 1 Yahoo Jiro Python 2 Yahoo Hanako Ruby 2 Yahoo Saburo PHP 3 Yahoo Sirou Perl mysql> EXPLAIN SELECT team_name FROM team WHERE team_id IN (SELECT team_id FROM member WHERE skill IN ("C")); 最初に実行される ことを期待 ①skill=Cを探す②team_id=1を探す • memberテーブルを1回読み込む • teamテーブルを1回読み込む • 合計＝5 + 3 = 8行の読み込みを期待する
- 44. 【3.相関サブクエリ】 実際の動き mysql> EXPLAIN SELECT team_name FROM team WHERE team_id IN (SELECT team_id FROM member WHERE skill IN ("C")); team_id team_name 1 Team1 2 Team2 3 Team3 team_id member_name skill 1 Yahoo Taro C 1 Yahoo Jiro Python 2 Yahoo Hanako Ruby 2 Yahoo Saburo PHP 3 Yahoo Sirou Perl team_id =1 AND skill=C のレコードを探す • 合計＝ 3 + 3 * 5 = 18行の読み込み • 実行計画の「PRIMARY」は外部表（親）を示す • なぜ、期待どうりに動かないのか？ • MySQLの仕様です。。。（5.6で改善されます）
- 45. 【3.相関サブクエリ】 チューニング方法(1) mysql> CREATE INDEX idx_skill ON member(skill, team_id); mysql> EXPLAIN SELECT team_name FROM team WHERE team_id IN (SELECT team_id FROM member WHERE skill IN ("C")); +----+--------------------+--------+------+---------------+-----------+省略+------+-------------+ | id | select_type | table | type | possible_keys | key | | rows | Extra | +----+--------------------+--------+------+---------------+-----------+省略+------+-------------+ | 1 | PRIMARY | team | ALL | NULL | NULL | | 3 | Using where | | 2 | DEPENDENT SUBQUERY | member | ref | idx_skill | idx_skill | | 1 | Using where | +----+--------------------+--------+------+---------------+-----------+省略+------+-------------+ •サブクエリの実行にインデックスを利用 •3 + 3 * 1 = 6行に（見積もり） +----+--------------------+--------+------+---------------+省略+------+-------------+ | id | select_type | table | type | possible_keys | | rows | Extra | +----+--------------------+--------+------+---------------+----+------+-------------+ | 1 | PRIMARY | team | ALL | NULL | | 3 | Using where | | 2 | DEPENDENT SUBQUERY | member | ALL | NULL | | 5 | Using where | +----+--------------------+--------+------+---------------+----+------+-------------+ インデックス未使用
- 46. 【3.相関サブクエリ】 チューニング方法(2) mysql> EXPLAIN SELECT team_name FROM team JOIN member USING(team_id) WHERE member.skill IN ("C"); +----+-------------+--------+--------+---------------+-----------+---------------------+------+ | id | select_type | table | type | possible_keys | key | ref | rows | +----+-------------+--------+--------+---------------+-----------+---------------------+------+ | 1 | SIMPLE | member | ref | idx_skill | idx_skill | const | 1 | | 1 | SIMPLE | team | eq_ref | PRIMARY | PRIMARY | test.member.team_id | 1 | +----+-------------+--------+--------+---------------+-----------+---------------------+------+ member表を先に読む • JOINに書き換える • 相関サブクエリ、だいたいJOINで書き直せる • オプティマイザが親子を自動判断 • member表を外部表（駆動表）にする +----+--------------------+--------+------+---------------+-----------+省略+------+-------------+ | id | select_type | table | type | possible_keys | key | | rows | Extra | +----+--------------------+--------+------+---------------+-----------+省略+------+-------------+ | 1 | PRIMARY | team | ALL | NULL | NULL | | 3 | Using where | | 2 | DEPENDENT SUBQUERY | member | ref | idx_skill | idx_skill | | 1 | Using where | +----+--------------------+--------+------+---------------+-----------+省略+------+-------------+
- 47. 代表的なチューニング例 1. type=ALL または type=index で rows が大きい 2. Extra に Using temporary; Using filesort でrowsが大きい 3. select_type が DEPENDENT SUBQUERY 4. JOINにおいて2つ目以降のExtraにUsing whereが出力さ ていて rows が大きい 5. 大量更新 6. データ削除 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 48. 【4.JOIN】NL結合 • MySQLは「NestedLoop結合」のみをサポート • どんな結合条件でも対応可 • 最速とは限らないがバランスの良いアルゴリズム Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 49. 【4.JOIN】NL結合 pref_id prefecture 1 Hokkaido 2 Aomori 3 Iwate pref_id name age 1 Yamada 20 1 Takana 33 2 Yamamoto 12 2 Ogawa 76 3 Inoue 90 ■ prefecture ■ people ■ cities - pref_id_idx mysql> EXPLAIN SELECT prefecture FROM prefecture INNER JOIN people USING(pref_id) WHERE people.age >= 120; +--+-----------+----------+----+-------------+-----------+--------------------+------+-----------+ |id|select_type|table |type|possible_keys|key | ref |rows |Extra | +--+-----------+----------+----+-------------+-----------+--------------------+------+-----------+ | 1|SIMPLE |prefecture|ALL |pref_id |NULL | NULL | 47| | | 1|SIMPLE |people |ref |pref_id_idx |pref_id_idx| prefecture.pref_id |173891|Using where| +--+-----------+----------+----+-------------+-----------+--------------------+------+-----------+ 上に表示される 表が外部表 pref_idカラムのインデックスを 利用して内部表からデータを取得 • NLはループの中にSELECTが入っているイメージ ： ： ： ：
- 50. 【4.JOIN】NL結合 pref_id prefecture 1 Hokkaido 2 Aomori 3 Iwate pref_id name age 1 Yamada 20 1 Takana 33 2 Yamamoto 12 2 Ogawa 76 3 Inoue 90 ■ prefecture ■ people ■ cities - pref_id_idx mysql> EXPLAIN SELECT prefecture FROM prefecture INNER JOIN people USING(pref_id) WHERE people.age >= 120; +--+-----------+----------+----+-------------+-----------+--------------------+------+-----------+ |id|select_type|table |type|possible_keys|key | ref |rows |Extra | +--+-----------+----------+----+-------------+-----------+--------------------+------+-----------+ | 1|SIMPLE |prefecture|ALL |pref_id |NULL | NULL | 47| | | 1|SIMPLE |people |ref |pref_id_idx |pref_id_idx| prefecture.pref_id |173891|Using where| +--+-----------+----------+----+-------------+-----------+--------------------+------+-----------+ ちょっと大きめ ： ： ： x47 17万行から age>=120を探す 47 ｘ 17万行 スキャン １７万行
- 51. 【4.JOIN】チューニング • ループ回数を少なくする • 結合条件以外の条件にマッチする件数を テーブルごとにカウント • 件数が少ないほうを外部表にする mysql> SELECT COUNT(*) FROM prefecture; +----------+ | COUNT(*) | +----------+ | 47 | +----------+ 1 row in set (0.00 sec) mysql> SELECT COUNT(*) FROM people where age >=120; +----------+ | COUNT(*) | +----------+ | 3 | +----------+ 1 row in set (0.70 sec) mysql> EXPLAIN SELECT prefecture FROM prefecture INNER JOIN people USING(pref_id) WHERE people.age >= 120; Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 52. 【4.JOIN】チューニング pref_id prefecture 1 Hokkaido 2 Aomori ～～～ ～～～ 41 Saga pref_id name age 1 Tokugawa 121 2 Toyotomi 125 ～～～～ ～～～～ ～～～～ 41 Akechi 130 3 Inoue 90 ■ people ： ■ people - age_idx ※ MySQLはクラスタインデックスのため主キー＝テーブルで実際はツリーです。 ・ 狙うべき動作
- 53. 【4.JOIN】チューニング mysql> EXPLAIN SELECT prefecture FROM prefecture INNER JOIN people USING(pref_id) WHERE people.age >= 120; +--+-----------+----------+------+--------------------+-------+---------------+----+-----------+ |id|select_type|table |type |possible_keys |key | ref |rows|Extra | +--+-----------+----------+------+--------------------+-------+---------------+----+-----------+ | 1|SIMPLE |people |range |pref_id_idx,age_idx |age_idx| NULL | 3|Using where| | 1|SIMPLE |prefecture|eq_ref|pref_id |pref_id| people.pref_id| 1|Using where| +--+-----------+----------+------+--------------------+-------+---------------+----+-----------+ 外部表が入れ替 わった mysql> CREATE INDEX age_idx ON people(age); Query OK, 0 rows affected (24.97 sec) ループは3回 1回のループに つき1行だけ • 3 x 1 行スキャン • Before: 4.3sec → After: 0sec Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 54. 代表的なチューニング例 1. type=ALL または type=index で rows が大きい 2. Extra に Using temporary; Using filesort でrowsが大きい 3. select_type が DEPENDENT SUBQUERY 4. JOINにおいて2つ目以降のExtraにUsing whereが出力さてい て rows が大きい 5. 大量更新 6. データ削除
- 55. 【6.大量の更新】 バルクインサートにより性能向上 INSERT INTO quote_real_info (ask10_flag, ask10_order, ask10_price, … ＜170カラムぐらい＞ VALUES (NULL, NULL, '1150’, '2012-06-13 15:10:00’, '0’, '900’, …）, (NULL, NULL, '1152’, '2012-06-13 15:10:01’, '0’, '300', …）, (NULL, NULL, '1153', '2012-06-13 15:10:00', '0', '100', …）, (NULL, NULL, '1250', '2012-06-13 15:10:01', '0', '920', …）, (NULL, NULL, '1151', '2012-06-13 15:10:00', '0', '500', …）, (NULL, NULL, '1155', '2012-06-13 15:10:01', '0', '150', …）);5万レコード /sec INSERT INTO quote_real_info (ask10_flag, ask10_order, ask10_price, … ＜170カラムぐらい＞ VALUES (NULL, NULL, '1150', '2012-06-13 15:10:00', '0', '900', …）; INSERT INTO quote_real_info (ask10_flag, ask10_order, ask10_price, … ＜170カラムぐらい＞ VALUES (NULL, NULL, '1150', '2012-06-13 15:10:00', '0', '900', …）; ： ：
- 56. 【6.大量の更新】チューニング方法 • RDBは通常コミット毎にDiskに書き込む •× Auto-Commit • バルクインサートはサーバ・クライアント間の通信 回数を減らせるため、より高速 • 1件1件コミット • 複数件コミット • バルクインサート 高速 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 57. 代表的なチューニング例 1. type=ALL または type=index で rows が大きい 2. Extra に Using temporary; Using filesort でrowsが大きい 3. select_type が DEPENDENT SUBQUERY 4. JOINにおいて2つ目以降のExtraにUsing whereが出力さてい て rows が大きい 5. 大量更新 6. データ削除 Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 58. 【7.テーブルの削除】 • TRUNCATE = DROP + CREATE • 注意：AUTO_INCREMENTがリセット • 条件を指定したい • パーティション化 ＋ [DROP|TRUNCATE] PARTITION DELETE FROM push_message； TRUNCATE TABLE push_message ； Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 59. チューニングの難しいクエリ
- 60. 必要なデータが大きいもの SELECT COUNT(*) FROM access_log; SELECT SUM(a) FROM access_log WHERE data BETWEEN ‘1995-01-01’ AND NOW(); 必要なデータが大きいものは遅い • MySQLは1セッション＝1スレッド＝１CPU • 作りから見直す必要がある • 例） 集計テーブルを作り更新時に同時にカウ ントアップする Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 61. まとめ
- 62. まとめ • カーディナリティとキーの指定順に注意 • スロークエリログで犯人を特定 • EXPLAINで分析 • チューニング方法は様々・ケースバイケース • → 経験あるのみ！ Copyright (C) 2016 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
- 63. おしらせ
- 64. MySQL Casual Slack • MySQL Casual の Slack （チャット） • 「MySQL Casual Slack」 で検索 Copyright (C) 2015 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 64
- 65. ありがとうございました