雑なMySQLパフォーマンスチューニング

1. MySQLのパフォーマンスチューニングについて少々 2016/01/20 yoku0825の中の⼈ GMOアドパートナーズグループ勉強会

2. ＼こんにちは／ yoku0825＠とある企業のDBA の中の⼈オラクれない- ポスグれない- マイエスキューエる- Twitter: @yoku0825 Blog: ⽇々の覚書 Oracle ACE Details MySQL 5.7 Community Contributor Award 1/141

3. このスライド書いた中の⼈です 2/141

4. ちなみに 3/141

5. というわけで安⼼して地雷友達 5.7 使っていいですよ :) 4/141

6. クエリーのライフサイクル client connection_handling parser optimizer executor handler storage_engine application mysqld 5/141

7. クエリーのライフサイクル Connection Handling Parser Optimizer Executor Handler Storage Engine 6/141

9. Connection Handling ソケット, ポートからの接続を待ち受ける接続があったらclone（またはスレッドキャッシュから取り出してディスパッチ）⼀次認証 8/141

11. Parser MySQLプロトコルのパース SQL構⽂のパース⼆次認証（データベース, テーブル単位のアクセス権限チェック）クエリーキャッシュ処理ジェネラルログ 10/141

13. Optimizer 統計情報の取得（Storage Engine APIを叩いてるっぽい）クエリーの書き換えを含めた実⾏計画の決定 12/141

15. Executor オプティマイザーから渡された実⾏計画の通りにHandlerを叩く Handlerから戻ってきた結果を使って実⾏計画の残りを実⾏ Using where; Using filesort; Using temporary; はコイツが頑張ってる証拠 - スローログ, バイナリーログ 14/141

17. Handler ストレージエンジンの抽象化レイヤーあんまり意識することはない 16/141

19. Storage Engine 実際にデータを格納するレイヤープラガブルアーキテクチャーなので、ほとんどの機能はこのレイヤーで実装されているストレージエンジンごとにトランザクション対応が違うとか - ストレージエンジンごとにロック粒度が違うとか- ストレージエンジンごとにバッファが違うとか- 18/141

20. クエリーのライフサイクル client connection_handling parser optimizer executor handler storage_engine application mysqld 19/141

21. どこが遅い︖ 20/141

22. どこが遅い︖ connection_handling parser optimizer executor handler storage_engine mysqld だいたいExecutor たまにStorage Engine 21/141

23. Executorが遅い理由 MySQLの不得意なことをやろうとしている⾊々パターンはあるけど、⼀⾔で⾔うならこれにあたる- Executorに仕事をさせたら負け 22/141

24. MySQLの不得意なこと複数のインデックスを使いこなす相関サブクエリー 23/141

25. 複数のインデックスに弱い理由 MySQLは原則1クエリー内で1つのテーブルあたり1つのインデックスしか使わないインデックスマージという例外が⼀応あるにはあるが、後付け - そもそもこういう設計思想なんだと思う- テーブルスキャンに強い/弱いはストレージエンジンのレイヤー MyISAMはスキャンに強く、InnoDBは弱い- 関数演算、（インデックスで解決できない）フィルター、（インデックスで解決できない）ソートはExecutorのお仕事（= 遅い） 24/141

26. EXPLAIN mysql> EXPLAIN SELECT * FROM table_1 a JOIN `table_2` s ON a.user_id=s.`user_id` AND s.site_i d=120 WHERE app_id=8250G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: a type: ref possible_keys: PRIMARY,ix_table_1,ix2_table_2,ix3_table_1,idx_table_1_06,idx_table_1_07,idx_t able_1_09 key: idx_table_1_06 key_len: 4 ref: const rows: 13496 Extra: *************************** 2. row *************************** id: 1 select_type: SIMPLE table: s type: ref possible_keys: idx_table_2_02,idx_table_2_03 key: idx_table_2_02 key_len: 4 ref: xxx.a.user_id rows: 1 Extra: Using where 2 rows in set (0.00 sec) 25/141

27. いくつかのルール Extra列はExecutorの都合それ以外はオプティマイザー、ハンドラー（= ストレージエンジン）の都合 key_len, rowsがヒントになる 26/141

28. type ALLがダメなんて良く⾔う ALL .. テーブルスキャン- ref .. 非ユニークキーによる選択- range .. レンジスキャン- 27/141

29. type どの⽅法でアクセスさせるのが最速だとオプティマイザーが⾒積もった結果特にInnoDBはクラスターインデックスなので、下⼿にセカンダリーインデックスを使うよりも本当に速いケースもある - MyISAMもスキャンに強いので、本当に速いケースがある - ダメなのはALLじゃなく、本当の最適なアクセスと違う時 rows, key_lenが判断の助けになる- 28/141

30. オプティマイザーが⾒誤る理由 InnoDBの統計情報がサンプリング1. オプティマイザーはLIMIT句を正しくハンドリングできない2. 29/141

31. InnoDBの統計情報 InnoDBの統計情報はテーブル全体から⼀部の情報をランダムに選び出し、全体を推測するサンプリング統計 5.5とそれ以前では1インデックスあたり8ページ（= 16kB * 8ページで128kB）でハードコード - 5.6とそれ以降では1インデックスあたりデフォルト20ページ（innodb_stats_persistent_sample_pages） CREATE TABLE, ALTER TABLEでテーブル単位でページ数を指定することも可能 - 30/141

32. InnoDBの統計情報サンプリングなので統計情報の再計算はそこまで（MyISAMと⽐べれば）⼤きくない - 統計情報が間違っている（著しく実際のデータの分布と乖離している）可能性が⾼い - 31/141

33. LIMIT句のハンドリング LIMIT句はORDER BY句の処理が終わってから実⾏される ORDER BY句の処理は最終的にExecutorで終端するので- つまりLIMIT句もExecutorの処理の範疇- オプティマイザーは⾃分より後のExecutorの動作を正しく⾒積もれないなので、ORDER BY .. LIMIT ..で効率的にORDER BY狙いのキーが使える場合でも、選んでくれないケースがある - 5.7でLIMITありの場合のオプティマイズが効くようになっている - 32/141

34. Extra: Using where; Using filesort; ExecutorがWHEREをフィルターしている、ExecutorがORDER BYのソートをしているインデックスを使って⾼速化できるのは WHERE, ORDER BY, GROUP BY, select_list どうすればいいかと⾔われると、「インデックス使う」としか⾔いようがない 33/141

35. トランプの話をします 34/141

36. Query As A Card 100枚のトランプが裏返して積まれた⼭があります何組かのトランプを混ぜたもので何が何枚⼊ってるかはわかりません 35/141

37. この⼭の中からスペードのAを探してください 36/141

38. どうするかというと⼭の⼀番上のトランプをめくる1. スートと番号を⾒る2. スペードのAだったら⼿元に残す3. スペードのAじゃなかったらどっかに置いておく4. ⼭の全てのカードに対して2, 3, 4を繰り返す⼭にスペードのAが何枚あるかに関わらず、⼭の全てのカードに対して繰り返す 5. 37/141

39. これがtype: ALLかつExtra: Using where トランプをめくる .. ⾏をフェッチするスートと番号を⾒る .. Executorでのフィルター処理 38/141

40. この⼭の中からスペードを全て探し出して、K〜Aの順で並べてください 39/141

41. どうするかというと右⼿で⼭の⼀番上のトランプをめくる1. スートと番号を⾒る2. スペードだったらそのカードを左⼿に残しておく3. スペードじゃなかったらどっかに置いておく4. ⼭の全てのカードに対して2, 3, 4を繰り返す5. ⼭から全てのスペードが出揃ったら、⼿元のカードをK〜A まで順番に並べる 6. 40/141

42. これがtype: ALLかつExtra: Using where; Using filesort トランプをめくる .. ⾏をフェッチするトランプをめくった右⼿ .. リードバッファースートを⾒る .. Executorでのフィルター処理スートが⼀致した時にカードを⼊れた左⼿ .. ソートバッファー⼿元のカードを並べ替える .. Executorによるクイックソート 41/141

43. KEY(suit) suit 上から club 3,5,13,14,16,18,19,20,37,44,45,55,57, 63,66,81,86,87,91,92,98,99,100 diamond 1,4,15,17,21,22,25,27,31,34,39,50,56, 58,60,65,68,70,72,73,78,97 heart 6,7,10,12,24,26,32,36,38,40,41,43,48, 51,52,61,62,67,74,75,84,85,88,89,90,9 3,95 spade 2,8,9,11,23,28,29,30,33,35,42,46,47,4 9,53,54,59,64,69,71,76,77,79,80,82,8 3,94,96 42/141

44. ここからスペードのAを探す suit 上から club 3,5,13,14,16,18,19,20,37,44,45,55,57, 63,66,81,86,87,91,92,98,99,100 diamond 1,4,15,17,21,22,25,27,31,34,39,50,56, 58,60,65,68,70,72,73,78,97 heart 6,7,10,12,24,26,32,36,38,40,41,43,48, 51,52,61,62,67,74,75,84,85,88,89,90,9 3,95 spade 2,8,9,11,23,28,29,30,33,35,42,46,47,4 9,53,54,59,64,69,71,76,77,79,80,82,8 3,94,96 43/141

45. スペードのAを探すトランプの上から2, 8, 9, .. 枚目を順番にめくり1. 番号を⾒る（スペードのものだけめくってるんだから、スートは⾒る必要がない） 2. Aだったらそのカードを残しておく3. Aじゃなかったらどっかに置いておく4. 44/141

46. これがtype: ref, ref: const, Extra: Using where インデックス上からスペードを探して「上から2番目」の情報を得る 1. 上から2番目のカードをめくる .. ここまでha̲index̲read2. Aかどうかを判定する .. Executorによるフィルター3. インデックス上の全てのリーフをさらうまで繰り返す .. ha̲index̲nextがHA̲ERR̲END̲OF̲FILEを返すまでループ 4. 45/141

47. ここからスペードを全て探し出して、K〜Aの順で並べる suit 上から club 3,5,13,14,16,18,19,20,37,44,45,55,57, 63,66,81,86,87,91,92,98,99,100 diamond 1,4,15,17,21,22,25,27,31,34,39,50,56, 58,60,65,68,70,72,73,78,97 heart 6,7,10,12,24,26,32,36,38,40,41,43,48, 51,52,61,62,67,74,75,84,85,88,89,90,9 3,95 spade 2,8,9,11,23,28,29,30,33,35,42,46,47,4 9,53,54,59,64,69,71,76,77,79,80,82,8 3,94,96 46/141

48. スペードを全て探し出して、K〜Aの順で並べるトランプの上から2, 8, 9, .. 枚目を順番にめくり左⼿に取る 1. 番号を⾒て、並べ替える2. 47/141

49. type: ref, ref: const, Extra: Using filesort インデックス上からスペードを探して「上から2番目」の情報を得る 1. 上から2番目のカードを左⼿に .. ha̲index̲readしてソートバッファーに詰める 2. 番号を⾒て並べ替える .. Executorによるクイックソート3. 48/141

50. KEY(suit, number) suit number 上から club 2 13,20 club 3 18,45 .. .. .. heart 13 85 spade 1 2,23,47,76 spade 2 77 spade 3 83 .. .. .. spade 11 11,33,35,96 spade 12 49,59,80 49/141

51. ここからスペードのAを探す suit number 上から club 2 13,20 club 3 18,45 .. .. .. heart 13 85 spade 1 2,23,47,76 spade 2 77 spade 3 83 .. .. .. spade 11 11,33,35,96 spade 12 49,59,80 50/141

52. スペードのAを探すトランプの上から2, 23, 47, 76枚目を順番にめくる（おしまい︕）インデックスの情報だけで完結するため、⼭を全て⼿繰る（不要なものをフェッチする）必要がない 1. 51/141

53. type: ref, ref: const, const インデックス上から(スペード, 1)を探して「上から2番目」の情報を得る 1. 上から2番目のカードを取る .. ha̲index̲read2. インデックス上の全てのリーフをさらうまで繰り返す .. ha̲index̲nextがHA̲ERR̲END̲OF̲FILEを返すまでループ 3. 52/141

54. スペードを全て探し出して、K〜Aの順で並べる suit number 上から club 2 13,20 club 3 18,45 .. .. .. heart 13 85 spade 1 2,23,47,76 spade 2 77 spade 3 83 .. .. .. spade 11 11,33,35,96 spade 12 49,59,80 Kなかった。。 53/141

55. スペードを全て探し出して、K〜Aの順で並べるトランプの上から49, 59, 80枚目を⼿に取る1. トランプの上から11, 33, 35, 96枚目を⼿に取る2. 全てのスペードのカードぶん1, 2を繰り返す3. 54/141

56. type: ref, ref: const, const, Extra: Using index インデックス上から(スペード, 最後のノード)を探して「上から49番目」の情報を得る 1. 上から49番目のカードを取る .. ha̲index̲read2. インデックス上の全てのリーフをさらうまで繰り返す .. ha̲index̲prevがHA̲ERR̲END̲OF̲FILEを返すまでループ 3. 55/141

57. :(;ﾞﾟʼωﾟʼ): Extra: Using whereが消えなかったたまに消えないたぶんオプティマイザーのバグ（ORDER BYと混じると Executorが仕事してなくてもUsing whereが消えない） 56/141

58. KEY(number) number 上から 1 2,22,23,26,47,76,93 2 4,13,20,25,75,77 .. .. 12 16,31,41,49,59,68,73,80,91 13 19,58,85 57/141

59. ここからスペードのAを探すインデックスからAを探して、「2, 22, 23, ..枚目」の情報を得て 1. ひっくり返してスペードかどうかを判定する2. Aのリーフが全部終わったら終わり3. type: ref, ref: const, Extra: Using where 58/141

60. スペードを全て探し出して、K〜Aの順で並べるインデックスからKを探して19, 58, 85枚目を⼿に取る1. スペードなら⼿元に、そうでなければよける2. カードの⼭全てに対して1, 2を繰り返す3. 59/141

61. type: index, Extra: Using where ただしこれはLIMITがない場合はテーブルスキャンを選んでた 5.6の場合、LIMITがあってもテーブルスキャンを選ぶ- そりゃ、結局全部のカードを裏返してるから、頭から全部ひっくり返した⽅が速い LIMITがある= 「枚数が揃ったらそこでそれ以降の結果セットは考慮する必要がない」 - この条件にマッチした場合、フェッチする⾏数を⼤幅に減らせる - 60/141

62. インデックスのイメージインデックスはソート済みのデータの部分複製（異論は認める） root club spade 2 3 2 13 20 18 45 77 B+Treeじゃないけど取り敢えずそこまで気にしない 61/141

63. インデックスのリーフ root club spade 2 3 2 13 20 18 45 77 MyISAMの場合はMYDファイルの先頭からのオフセットバイト数 InnoDBの場合はクラスターインデックスの値 62/141

64. InnoDBのクラスターインデックスイメージ root club spade 3 5 13 14 2 23 root p3 p5 p13 p14 p2 p23 Club-A Club-4 Club-2 Club-5 Spade-A Spade-A Secondary Index Clustered Index 63/141

65. InnoDBでWHERE狙いのキー SELECT * FROM card USING(idx_suit) WHERE suit= 'club' ORDER BY number LIMIT 1; root club spade 3 5 13 14 2 23 root p3 p5 p13 p14 p2 p23 Club-A Club-4 Club-2 Club-5 Spade-A Spade-A Secondary Index Clustered Index 64/141

66. InnoDBでWHERE狙いのキー SELECT * FROM card USING(idx_suit) WHERE suit= 'club' ORDER BY number LIMIT 1; root club spade 3 5 13 14 2 23 root p3 p5 p13 p14 p2 p23 Club-A Club-4 Club-2 Club-5 Spade-A Spade-A Secondary Index Clustered Index 65/141

67. InnoDBでWHERE狙いのキー SELECT * FROM card USING(idx_suit) WHERE suit= 'club' ORDER BY number LIMIT 1; root club spade 3 5 13 14 2 23 root p3 p5 p13 p14 p2 p23 Club-A 1 Club-4 Club-2 Club-5 Spade-A Spade-A Secondary Index Clustered Index 66/141

68. InnoDBでWHERE狙いのキー SELECT * FROM card USING(idx_suit) WHERE suit= 'club' ORDER BY number LIMIT 1; root club spade 3 5 13 14 2 23 root p3 p5 p13 p14 p2 p23 Club-A 1 Club-4 Club-2 Club-5 Spade-A Spade-A Secondary Index Clustered Index 67/141

69. InnoDBでWHERE狙いのキー SELECT * FROM card USING(idx_suit) WHERE suit= 'club' ORDER BY number LIMIT 1; root club spade 3 5 13 14 2 23 root p3 p5 p13 p14 p2 p23 Club-A 1 Club-4 2 Club-2 Club-5 Spade-A Spade-A Secondary Index Clustered Index 68/141

70. InnoDBでWHERE狙いのキー SELECT * FROM card USING(idx_suit) WHERE suit= 'club' ORDER BY number LIMIT 1; root club spade 3 5 13 14 2 23 root p3 p5 p2 p23 p13 p14 Club-A 1 Club-4 2 Club-2 3 Club-5 4 Spade-A Spade-A Secondary Index Clustered Index フェッチした⾏をクイックソートしてからLIMITを評価 69/141

71. InnoDBでORDER BY狙いのキー SELECT * FROM card USING(idx_number) WHERE suit= 'club' ORDER BY number LIMIT 1; root A 2 2 22 23 26 4 13 root p2 p22 p23 p26 p4 p13 Spade-A Diamond-A Spade-A Heart-A Diamond-2 Club-2 Secondary Index Clustered Index 70/141

72. InnoDBでORDER BY狙いのキー SELECT * FROM card USING(idx_number) WHERE suit= 'club' ORDER BY number LIMIT 1; root A 2 2 22 23 26 4 13 root p2 p22 p23 p26 p4 p13 Spade-A 1 Diamond-A 2 Spade-A 3 Heart-A 4 Diamond-2 5 Club-2 6 Secondary Index Clustered Index LIMIT件数が早めに⾒つかれば勝ち、そうでなければ負け。ところでこれ、何かに似てると思いません︖ 71/141

73. InnoDBでcovering index SELECT * FROM card USING(idx_number) WHERE suit= 'club' ORDER BY number LIMIT 1; root club spade 2 3 A 13 20 18 45 2 23 root p13 p20 p18 p45 p2 p23 Club-2 1 Club-2 Club-3 Club-3 Spade-A Spade-A Secondary Index Clustered Index 72/141

74. WHERE狙いのキー, ORDER BY狙いのキー WHEREとORDER BY .. LIMITを同時にカバーできるインデックスが作成できない時に WHEREをストレージエンジンに任せてフェッチする⾏を減らしてファイルソートをExecutorにやらせるか - ORDER BY .. LIMITをストレージエンジンに任せて ExecutorにフィルターさせつつLIMITでループを抜けるのを期待するか - 73/141

75. WHERE狙いのキー, ORDER BY狙いのキー「JOINが遅い」はJOINが遅いんじゃなくてJOINの参照表でソートしようとしてExecutorがソートしちゃってるケースあとはオプティマイザーにバグがあって、駆動表を Executorがフィルターして参照表の参照回数が減る可能性を考慮していない。 - See also, http://www.slideshare.net/yoku0825/ whereorder-by 74/141

76. Executorに仕事をさせたら負け 75/141

77. Executorが必要以上の仕事をしていないか GROUP BYのケースを除いて、Rows_sent= Rows_examinedが⼀番良い MySQLにはヒストグラム統計がないので、WHERE狙いと ORDER BY狙いのどちらが本当に速いのかMySQLは知らない（憶えてない） 76/141

78. Executorが必要以上の仕事をしていないか⼈間は得てして正しい統計情報を知っているケースがあるサービスの特性（⼥性は少ないからWHERE gender= 'F' ORDER BY birthdayはWHEREで狙った⽅がいいだろうし、 WHERE gender= 'M' ORDER BY birthdayはORDER BY狙いの⽅が良いだろう、とか） - サンプリングでない実際の分布（InnoDBの統計情報は飽くまでサンプリングなのでたまに踏み外す） - LIMITの考慮（5.6とそれ以前のMySQLはORDER BY .. LIMITの時でも積極的にWHEREを狙う） - 77/141

79. オプティマイザーの強化 MySQL 5.6 Multi-Range Read, Batched Key Access(デフォルトOFF), Semi-JOIN, Materialized MySQL 5.7 ORDER BY .. LIMIT Optimization, Configurable cost Model, JOIN optimization 78/141

80. 迷ったら最新（オプティマイザーに関しては） 79/141

83. 古いMySQLに慣れていると、⼾惑うことも「MySQLはこう間違うだろう」という予測と違う間違え⽅をする EXPLAIN EXTENDED, SHOW WARNINGSでオプティマイザーがクエリーをどう書き換えたか表⽰できる mysql57> show warningsG *************************** 2. row *************************** Level: Note Code: 1003 Message: /* select#1 */ select `d1`.`Country`.`Code` AS `Code`,`d1`.`Country`.`Name` AS `Name `,`d1`.`Country`.`Continent` AS `Continent`,`d1`.`Country`.`Region` AS `Region`,`d1`.`Country `.`SurfaceArea` AS `SurfaceArea`,`d1`.`Country`.`IndepYear` AS `IndepYear`,`d1`.`Country`.`Po pulation` AS `Population`,`d1`.`Country`.`LifeExpectancy` AS `LifeExpectancy`,`d1`.`Country`. `GNP` AS `GNP`,`d1`.`Country`.`GNPOld` AS `GNPOld`,`d1`.`Country`.`LocalName` AS `LocalName`, `d1`.`Country`.`GovernmentForm` AS `GovernmentForm`,`d1`.`Country`.`HeadOfState` AS `HeadOfSt ate`,`d1`.`Country`.`Capital` AS `Capital`,`d1`.`Country`.`Code2` AS `Code2` from `d1`.`Count ry` semi join (`d1`.`City`) where ((`d1`.`City`.`CountryCode` = `d1`.`Country`.`Code`) and (` d1`.`Country`.`Continent` = 'Asia') and (`d1`.`City`.`Population` > (`d1`.`Country`.`Populati on` / 2))) 2 rows in set (0.00 sec) 82/141

84. sysスキーマ performance̲schema, information̲schemaのビューと、 performance̲schema関連の設定をゴニョるプロシージャの詰め合わせなのでperformance_schema= ONが⼤前提- 合わせて使いたいinnodb_monitor_enable= all- 5.6の場合はgitリポジトリーからcloneしてsqlスクリプト実⾏ - 83/141

85. sys.statement̲analysis query full̲scanしてれば* exec̲count err̲count, warn̲count *̲latency rows̲sent̲avg, rows̲examined̲avg tmp̲tables, sort̲merge̲passes 84/141

86. Percona Server + log_slow_verbosity = query_plan # Time: 130601 8:01:06.058915 # User@Host: root[root] @ localhost [] Id: 42 # Schema: imdb Last_errno: 0 Killed: 0 # Query_time: 7.725616 Lock_time: 0.000328 Rows_sent: 4 Rows_e xamined: 1543720 Rows_affected: 0 # Bytes_sent: 272 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_s izes: 0 # QC_Hit: No Full_scan: Yes Full_join: No Tmp_table: No Tmp_t able_on_disk: No # Filesort: No Filesort_on_disk: No Merge_passes: 0 85/141

87. Anemometer 86/141

88. 相関サブクエリー外側のクエリーが内側のサブクエリーの条件になっているケース内側のサブクエリーが外側の条件になるケースはMySQL ⽤語では単にサブクエリーと呼ぶ（個⼈的には明確に区別するために「キャッシャブルなサブクエリー」と呼んでる） - しかしWHERE INはキャッシャブルなサブクエリーのはずでも相関サブクエリーになるというダメ仕様が5.5とそれ以前にあってだな。。 - 87/141

89. シンプルな話、外側のクエリーに1⾏マッチするたびに内側のクエリーを実⾏してしまう⾏のフェッチのみならず、クエリーまるごと実⾏する。外側テーブルのサイズが⼤きくなると加速度的に遅くなるのはこのせい。 - mysql> SHOW PROFILE; +--------------------------------+----------+ | Status | Duration | +--------------------------------+----------+ | starting | 0.000023 | | .. | .. | | executing | 0.000006 | | Sending data | 0.000006 | | .. | .. | | executing | 0.000005 | | Sending data | 0.000014 | | executing | 0.000005 | | Sending data | 0.000047 | | end | 0.000010 | | .. | .. | +--------------------------------+----------+ 2000025 rows in set (4.78 sec) 88/141

90. 相関サブクエリーの書き換え⽅ 7割⽅JOINに書き換えられる JOINに落とし込んでUSE INDEXまでつければ5.5とそれ以前でも戦える - どうしてもロジックとしてJOINに書き換えられないケースもある CREATE TEMPORARY TABLEを使って落とし込むのがいいテンポラリーテーブルはクラッシュアンセーフ（更新ステートメントには使わない︕ ）そもそもクラッシュアンセーフだから迷わずMyISAM を選んでいい⼤した量でなくてもインデックス張る。劇的に違う - のがいい、というか、SQLだけでやるにはそれしかない- 89/141

91. 書き換える時に必要なもの再帰テスト無いと死ぬ- ポジション上、返す結果が変わらないことの担保をしないといけないパラメーター渡して、新旧クエリーの2パターン投げて結果を⽐較するだけでも取り敢えずいいんだ最近はコマンドラインクライアントで REPEATABLE-READでトランザクション内でやればオブジェクト⽐較するだけで済む分布に極端な偏りがあるパラメーターはいくつかバリエーションを⽤意した⽅がいい（同じ形をしていてもパラメーターで実⾏計画は変わる） - 90/141

92. ひとやすみ 91/141

93. Storage Engineが遅い理由リソースが⾜りていない1. パラメーターが適切でない2. キャッシュミスヒット3. ロックやmutexの競合（並列度が⾼すぎる）4. バルク操作5. 92/141

94. リソースが⾜りていないホットデータが100GBあるのにInnoDBバッファプールが 16GBしかなかったら︖ 物理メモリーが64GBしかないのに innodb_buffer_pool_size= 128Gにしたら︖ 50並列でクエリーを実⾏するのに8コアしかなかったら︖ 秒間1000コミットあるのにIOPSが200しかなかったら︖ 93/141

95. パラメーターが適切でない innodb_buffer_pool_size innodb_log_file_size * innodb_log_files_in_group innodb_flush_method innodb_log_buffer_size innodb_flush_log_at_trx_commit innodb_io_capacity, innodb_io_capacity_max 94/141

96. innodb̲buffer̲pool̲size InnoDBの動作の要個⼈的にはキャッシュじゃなくてデータの本体- ⾜りてないとSELECTだけじゃなく全ての動作が遅いただしDROP TABLEとTRUNCATE TABLEはバッファプールが⼤きければ⼤きいほど遅くなる 95/141

97. InnoDBの動作の要 SELECTのときバッファプールを⾒るあればそれを使うなければテーブルスペースファイルを読んでバッファプールに載せるバッファプールがいっぱいだったら⼀番古いのを追い出してバッファプールに載せる追い出そうとしたページがダーティーページだったらフラッシュしてから追い出す - 96/141

98. InnoDBの動作の要 INSERT, UPDATE, DELETEのとき UNDOとログはちょっと省略 - UPDATE, DELETEの時にPRIMARY KEY以外の属性で絞り込む場合は、SELECTと同様にバッファプールを使って検索する - 97/141

99. InnoDBの動作の要 INSERT, UPDATE, DELETEのときデータそのものの追加, 更新, 削除は最終的にクラスターインデックスの値から、書き込むページ番号を特定するバッファプールはCOMMIT前に更新される（COMMIT されてるかどうかのフラグがある） READ-UNCOMMITTEDはバッファプールから読んで COMMITされてるかどうかのフラグを⾒ない COMMITされてるかどうかに関わらず、古いファイルはUNDOセグメントに移されて、そのページ番号がページに書き込まれる - 98/141

100. 対象のページがバッファプールに載っていればバッファプール上のデータを書き換える InnoDBのDELETEは論理削除- バッファプールのページに「delete mark」を付ける- まだテーブルスペースファイルに反映されてないページのことを「ダーティーページ」と呼ぶダーティーページはバッファプールから押し出される時にテーブルスペースファイルにフラッシュされなければいけない - 99/141

101. 対象のページがバッファプールに載っていなければテーブルスペースファイルを読んでバッファプールに載せてから書くバッファプールに載せてからINSERT- バッファプールに載せてからUPDATE- バッファプールに載せてからDELETE- Replication Booster for MySQLやinnodb̲fake̲changes はこの仕組みを利⽤したもの 100/141

102. DROP TABLE, TRUNCATEのとき TRUNCATEは内部的にDROP TABLE, CREATE TABLE ディクショナリーから参照を切るバッファプール上の全てのページをチェックし、そのテーブルのページがあれば破棄する「バッファプールに載せてdelete mark」はしない- 101/141

103. ROW̲FORMAT= Compressed InnoDB圧縮圧縮はページ単位、圧縮したままでは読むことも書くこともできないバッファプールに圧縮状態のまま読み込むa. バッファプール上で解凍してコピーするb. 解凍済みのページに対する操作をするc. 解凍済みのページがフラッシュされる時に再圧縮されて圧縮状態のページが更新される（再圧縮） d. 圧縮状態のページはバッファプールにもう少し残るe. ただでさえ重いディスクアクセスのタイミングで圧縮/解凍処理が加わる。 102/141

104. InnoDB圧縮のワーストケース SELECTクエリーがやってきて1. バッファプールミスヒット2. バッファプールの空きが無い3. ⼀番古いページを押し出す4. ⼀番古いページがダーティーページだったら︖5. 再圧縮してフラッシュ6. 空けたページに圧縮状態のページを持ってきて7. 解凍してコピー8. 103/141

105. InnoDB圧縮はバッファプール効率とCPU効率を犠牲にして容量を稼いでいる IO回数が減らせるという側⾯もあるけれど、余程の場合でない限り⽀払う代償は⼤きいバッファプールにミスヒットした時だけやたら重い（20ms => 400msオーバーとか） - しかも実際にSELECTするとバッファプールに載るから、スローログ⾒てSELECTした時は全然遅くないとか - 104/141

106. innodb̲buffer̲pool̲sizeだいじ⼩さすぎると（ほぼ）全てのクエリーが遅くなる特にInnoDB圧縮を使うならデータサイズの1.5倍以上あってもいい 105/141

107. innodb̲log̲file̲size * innodb̲log̲files̲in̲group バッファプールが更新されてからテーブルスペースファイルに反映されるまでの中間状態がInnoDBログテーブルスペースに即時反映されなくともログファイルに即時反映を保証することでデータの永続性を担保する - ログファイルに即時反映を保証できなくなると、データの保護のためInnoDBはトランザクション処理を中断する（シャープチェックポイント） - 106/141

108. innodb̲log̲file̲size * innodb̲log̲files̲in̲group ⾜りているか , ⾜りていないかの⼆軸なので、⾜りていれば⼤きすぎる必要もないし、⾜りていなければどんどん⼤きくしないといけない⼤きすぎるとクラッシュリカバリー終わらないって話があるけど、MySQL 5.5以降でログファイルサイズによるクラッシュリカバリーが終わらないって話はそうそうない（⻑くて数分程度） - innodb_flush_method= O_DIRECTでもページキャッシュされる（O̲DIRECTで開くのはテーブルスペースファイルだけ）ので、ページキャッシュと相談 - 107/141

109. innodb̲log̲file̲size * innodb̲log̲files̲in̲group InnoDBログの性能は innodb_log_file_size と innodb_log_files_in_group の積にほぼ⽐例 64M * 3 と96M * 2 はほぼ同等の性能- ⾜りてるか⾜りてないかだから- 5.5とそれ以前はinnodb_log_files_in_groupのみを増やす場合のみ再作成不要 5.6とそれ以降は増やす時でも減らす時でもmy.cnfを書き換えて再起動するだけでいい。楽ちん。 - 108/141

110. InnoDBのデータ永続化 InnoDBはテーブルスペースファイル + ログファイルで初めて完全なデータバッファプールは (テーブルスペースファイル + ログファイル) の部分集合 - ある意味「フルバックアップ」と「バイナリーログ」からポイントインタイムリカバリーをするのに似ている - バッファプール上にあってテーブルスペースファイルにないデータ(ダーティページ)が⼀定割合を超えると強制チェックポイント - 109/141

111. innodb̲flush̲method テーブルスペースファイル(ibdata1, .ibd)のopenフラグを変更できる暗黙のデフォルトは実質fsync ファイルシステムキャッシュを併⽤しつつfsyncする - 使うとしてもO̲DIRECTくらいしかぱっと思いつかないファイルシステムキャッシュを通さずにfsyncするページキャッシュで節約したぶんをバッファプールに回せるブロックデバイスが対応している場合は、DMA転送が有効になるらしい（ioDriveがちょっぱやなのはこれが効いているらしい） - nosync, O_DIRECT_NO_FSYNCとか…わかるな︖- 110/141

112. innodb̲log̲buffer̲size InnoDBログのバッファログファイルがwriteされるまでの間、ログに書き込まれるべきデータはここにいる 1トランザクションが⼤きすぎてログバッファに⼊りきらないと途中でフラッシュ - innodb_flush_log_at_trx_commit = 0のときはここにありったけ詰め込まれる - ⼼当たりがあれば⼤きくすれば良いけどせいぜいMB単位なので⼤きくしてもいい - 111/141

113. innodb̲flush̲log̲at̲trx̲commit InnoDBログをsyncする頻度デフォルトは1。RDBMSとしては1であるべき。 innodb̲flush̲log̲at̲trx̲co mmit write fsync 0 InnoDBまかせ InnoDBまかせ 1 COMMITごと COMMITごと 2 COMMITごと 1秒に1回 112/141

114. InnoDBログとクラッシュ problem commit write sync detail mysqldクラッシュ OK OK OK データの⽋損なし OSクラッシュ OK OK OK データの⽋損なし mysqldクラッシュ OK OK Not yet データの⽋損なし OSクラッシュ OK OK Not yet データ⽋損 mysqldクラッシュ OK Not yet Not yet データ⽋損 OSクラッシュ OK Not yet Not yet データ⽋損 mysqldクラッシュ Not yet Not yet Not yet データの⽋損なし OSクラッシュ Not yet Not yet Not yet データの⽋損なし 113/141

115. innodb̲flush̲log̲at̲trx̲commit= 1 problem commit write sync detail mysqldクラッシュ OK OK OK データの⽋損なし OSクラッシュ OK OK OK データの⽋損なし mysqldクラッシュ OK OK Not yet データの⽋損なし OSクラッシュ OK OK Not yet データ⽋損 mysqldクラッシュ OK Not yet Not yet データ⽋損 OSクラッシュ OK Not yet Not yet データ⽋損 mysqldクラッシュ Not yet Not yet Not yet データの⽋損なし OSクラッシュ Not yet Not yet Not yet データの⽋損なし 114/141

118. 独断と偏⾒ MySQLが単体でダウンするよりはH/W障害で軒並みごっそりいかれる⽅が回数が多い気がするということはinnodb_flush_log_at_trx_commitは1か0（クラッシュしたら必ず毎回作り直す）が効率がいいと思う毎回作り直すことを前提に設計すれば、 innodb_log_group_home_dir= /dev/shm も可能 /dev/shmだとページキャッシュ⾷わないし更にはskip_innodb_doublewriteも使える - 117/141

119. innodb̲io̲capacity, innodb̲io̲capacity̲max ダーティーページのアダプティブフラッシュに使うIO回数を制限する 5.6で⼤幅に動作が変わっていて、5.5とそれ以前より⼤幅に下げないとバックグラウンドスレッドがIOを⾷い切る innodb_adaptive_flushing_lwmを上げるのもいいかも知れない 118/141

120. キャッシュミスヒット InnoDBの圧縮はミスヒットのコストがヒット時に⽐べて異様に⾼いテーブルキャッシュミスヒットは統計情報を再計算するのでインデックスの数が多いと重い APサーバーを再起動したタイミングで⼀⻫にSHOW FIELDS を取りに来るようなORMは「⼀⻫に」と相まって⼀瞬でテーブルキャッシュを⾷い尽くすことがある - クエリーキャッシュはヒット/ミスヒットに関わらずジャイアントロックがでかすぎ 119/141

121. ロックの競合（並列度が⾼いだけとは限らない）あるいは単にInnoDBが⾏ロックだと思い込んでロック粒度が適切でない InnoDBのロックはネクストキーロック- つまりインデックスロック- ネクストキーロックはインデックス間のギャップもロックギャップロックが避けたい場合はREAD-COMMITTED にするとまあまあ良くなる - sys.innodb̲lock̲waitsがロック解析を助けてくれる InnoDBは基本的に参照ロックフリー 120/141

122. Too many connectionsは⼤概並列度⾼すぎではない単にクエリーが遅い単にロックが競合してる単に性能限界を超えたmax_connectionsを設定してしまってる Connection Handlerをcloneして認証までしてから”Too many connections”の判定をするから、cloneの負荷はかかる - 稼げる時間は⼗数分、それもエラーを減らすために他のクエリーの速度を犠牲にする - ただしホントにmutexが変に刺さってもこれは出る（けど、頻度は少ない） mutexが刺さったならmysqldの再起動⼀択- 121/141

123. mutexの競合（並列度が⾼すぎる）ガチでmutexが詰まってる場合は%sysが跳ねあがることが多い InnoDBのmutexの詰まりはSHOW ENGINE INNODB STATUSで SEMAPHORESセクションにいっぱい吐くこうなると正直⼿の打ちようがほぼない- 多少IO処理を軽くしたりスレッドの数減らして再起動しても焼け⽯に⽔ - スケールアウト検討どき- ⾼負荷状況下で新機能を使うと刺さって残ることがたまにあるというか先週InnoDB Online DDLで変に刺さって再起動した - 122/141

124. バルク操作最初の戦略トランザクションの粒度をできるだけ（アトミック性を担保できるだけ）⼩さくするトランザクションが⼤きいとロックを取る時間が⻑くなる 5.5とそれ以前のスレーブSQLスレッドは同時に1つのクエリーしかさばけないためレプリケーションが遅延する 5.6でもスキーマが違わないとパラレルに動かない 5.7でテーブル単位もイケるらしいが未検証 - 123/141

125. バルク操作トランザクションが⼩さいと InnoDBログにフラッシュする回数が多くなる- ダブルライトの回数が多くなる（ライトコンバインドが効きにくくなる） - バイナリーログエントリーが増えるのでI/Oと帯域に注意- 124/141

126. バルク操作新しいインスタンスをスレーブで⽴てて、そっち側でバルク更新 skip_innodb_doublewrite, innodb_flush_log_at_trx_commit= 0, skip_log_bin, skip_slow_query_log - バルク操作を分割して並列化- 切り替え時にショートメンテが必要（テーブルごとデータの転送）他のスレーブがあった場合、そっちにも転送しないといけない 5.6とそれ以降ならFLUSH TABLE FOR EXPORTを使ってテーブル単位でファイルコピーできる - 125/141

127. バルク操作 pt-online-schema-changeを流⽤してしのぐ pt-online-schema-changeは5.5とそれ以前のバージョンでもオンラインでALTER TABLEを実現できるように作られたハックの粋が詰まったスクリプト - 要はトリガーとREAD-COMMITTEDを使って上⼿いこと新しいテーブルにデータを移す - 126/141

128. pt-oscの仕組みオリジナルテーブルの定義をコピーしてクローンテーブルを作るクローンに対して定義の操作をするオリジナルにトリガーをかけ、オリジナルに対する更新をクローンに伝播させる READ-COMMITTEDでオリジナルからクローンに少しずつデータをコピーデータがコピーし終わったらRENAME TABLEでオリジナルとクローンを⼊れ替える 127/141

129. pt-oscの流⽤でバルク操作トリガーを⼿で（か、pt-oscを中途半端に終わらせてトリガーを残す）張ってpt-archiverとか使うとレプリケーション遅延とかもチェックしてくれて便利スレーブを使う⽅法に⽐べてショートメンテは要らない pt-oscと同じデメリットがある最⼤でテーブルサイズの2倍以上の空き容量が必要デッドロック発⽣の可能性トリガー処理分のレスポンスタイムのオーバーヘッド数回のメタデータロック - 128/141

130. バルクデリートが遅い InnoDBのDELETEは論理削除、だがクラスターインデックスだけは再編成する- 5.5とそれ以降ならセカンダリーインデックスはチェンジバッファが効いて非同期にマージそれ以前の場合、⾏を消すということは必ず全てのセカンダリーインデックスに更新が⾛るので超重い - DELETEの場合、クラスターインデックスのリーフを削除するので場合によっては再編成が⾛る B+Treeはツリーの再編成が重い- 129/141

131. 容量との戦い DELETEは⼀度拡張したテーブルスペースを縮⼩させない空き領域が再利⽤されるので、テーブルスペースのサイズがそこで頭打ちになる、程度。 - テーブルスペースを⼩さくするにはOPTIMIZE TABLEが必要。ただしInnoDBでinnodb_file_per_table= 0の場合は OPTIMIZE TABLEでも⼩さくならない。この設定だとDROP TABLEやTRUNCATEでも決して⼩さくならないので結構⾯倒。 - 130/141

132. 容量との戦いオンラインでOPTIMIZE TABLE pt-oscなら5.5や5.6.16とそれ以前でもオンラインでできるただしオリジナルテーブルを残したままクローンテーブルに⾏をコピーするので、（容量的な意味での）最⼤瞬間風速に注意。 - InnoDBネイティブのオンラインALTER TABLEができるようになるのは5.6.17とそれ以降 - 更新がそこまで多くないテーブルなら（秒間数千叩かれ続けるようなのは⾟かった）5.6.17以降を使うのが簡単でいい - 131/141

133. 容量との戦いタイトになるのがわかってる時はパーティショニングしてる削除条件が設計段階できれいに決まっているなら、それに合わせてパーティショニングすることでALTER TABLE TRUNCATE PARTITIONが使える。 - 12か⽉保存のためにPARTITION BY LIST ((YEAR (register_date) MOD 2)* 100 + MONTH(register_date)) で24パーティション確保して13か⽉目にTRUNCATE PARTITIONするとか - 132/141

134. 容量との戦い int型かsmallint型か、timestamp型かdatetime型かは多くの場合どうでもいい 2バイトの差= 10億⾏でやっと2GB- インデックスの数に⽐例するけど、それでも⽂字列型に⽐べれば全然⼤したことない - テーブルのサイズは基本的にvarcharに⽀配される EUC, SJISは2バイト、UTF-8は3バイト（utf8mb4の場合は最⼤で4バイト⽂字も⼊る） - とはいえユーザーコンテンツはどうしようもないんだよなぁ。。垂直シャードするのがギリギリのライン。。 - 133/141

135. 論理削除個⼈的には好きじゃないやるなら、これは守っておいた⽅がいい整数型かENUM型（でないとc.が守りにくい）a. 全てのセカンダリーインデックスの先頭に削除フラグのカラムが存在しなければならない b. 決して”=”以外の演算⼦を使わない（NOTとかダメ、絶対） c. ”=”演算⼦で等価⽐較するものを全てのWHERE句の先頭につける d. これ以外で迂闊に使うと、あっという間にExecutorさんが頑張る世界線に突⼊する 134/141

136. Questions and/or Suggestions? 135/141

137. Question MySQL 5.5からそれ以降にアップグレードするにあたって注意事項はある︖ 5.6ではInnoDBのバックグラウンドスレッドが活発になっているのでinnodb̲io̲capacityを減らす、メモリーを⼤⾷いになったので「物理メモリーの75%」よりも減らしておくと良い。 SQL的な非互換はほぼない。 5.7はsql̲modeのデフォルト値に変更があったので明⽰的に sql_mode= ''をコンフィグに記載しないとSQLが非互換。 sql̲modeが同じでも多少の非互換があり、古いRailsだと migrationに失敗する。いくつか古いオプションが削除になっている。 136/141

138. Question オプティマイザーだけアップグレードとかできない︖ できません＞＜ 137/141

139. Question Using whereとUsing filesort、どっちが悪いっていう指標はあるの︖ フェッチするのが2⾏だったらUsing whereでもUsing filesort でも構わないけどフェッチするのが1000万⾏だったらダメだよね、という感じなので、Rows_sentとRows_examinedの⽐率で⽐べるのがいいんじゃ。 138/141

140. Question InnoDBの統計情報をサンプリングではなく全ページをスキャンにはできないの︖ グローバル変数またはテーブル単位でページ数を指定できるので、それを⼗分⼤きくすれば全ページをスキャンした統計情報は可能。ただ、5.5で知⼈が試した限り遅かったらしい。 139/141

141. Question MyISAMならALTER TABLE .. ORDER BY ..で降順のインデックスを作れる︖ インデックス上は必ず昇順。ALTER TABLE .. ORDER BY ..で並べ替えられるのはデータファイル上の並び順。 MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.1.7 ALTER TABLE 構⽂ 140/141

142. Question MySQLからMariaDBに移⾏したら性能があがった。考えられる要因は︖ MariaDBのオプティマイザーは性能が良い。MariaDBの InnoDBはPerconaが開発しているXtraDBなのでちょっとだけいい。バイナリーログのグループコミットが性能が良く、スレーブの遅延が起きにくい。メディアではMariaDBは使っている︖ スレッドプールプラグインが使いたくて導⼊したことがあったが、ワークロード的にMySQLより遅くなったので、より MySQLに近いPercona Serverに移⾏した。 141/141

雑なMySQLパフォーマンスチューニング

yoku0825

雑なMySQLパフォーマンスチューニング

A particular slide catching your eye?