MySQL 5.7 初心者向けセミナー ~チューニング基礎編、SQLチューニング編~ 20170814

セミナー関連のツイートをまとめました 【追加】20170816、@yyamasaki1さんからの補足を末尾に追加しました。
10
前へ 1 ・・ 6 7
しょー(show) @surumegohan

5.7から追加されたオプティマイザヒント。 構文をコメントとしてSQLに記載する。 構文が間違っててもコメントになるのでスルーされる点に注意 #mysql_jp

2017-08-14 17:17:54
しょー(show) @surumegohan

サブクエリだけ指定できるのでoptimizer_switchより細かい制御ができるようになる。 #mysql_jp

2017-08-14 17:18:33
しょー(show) @surumegohan

オプティマイザヒントはかなり突っ込んだチューニングになるので入門レベルではないです。。。 頭の片隅においておいてください。 #mysql_jp

2017-08-14 17:22:21
しょー(show) @surumegohan

オプティマイザヒントは8.0以降も今後改善計画がある。 新しいヒントの追加や既存ヒントのリプレースなど。 #mysql_jp

2017-08-14 17:23:30
しょー(show) @surumegohan

チューニングがうまくいかない場合は? → 商用版を契約しているならばチューニングに関する問い合わせもサポートします。スタンダードエディションでも。年間24万円。月当たり2万円です。詳細はMySQLコンサルティング・サポートをご参照ください #mysql_jp

2017-08-14 17:25:45
しょー(show) @surumegohan

オプティマイザ。4テーブルの場合でもJOINを順番に行う。2テーブルずつJOINするという動きはしない。 #mysql_jp

2017-08-14 17:27:10
しょー(show) @surumegohan

オプティマイザの特性として、クエリ間の特性はない。あくまで単一クエリに対する最適化のみ。 #mysql_jp

2017-08-14 17:27:50
しょー(show) @surumegohan

統計情報永続化。5.6から。5.5まではサーバ再起動すると統計情報を保存してませんでした。5.6以降の方が実行計画が安定する。サンプリングの精度をあげたければ、その方法も資料にあるので参考にしてください。 再計算を無効化することもできます。 #mysql_jp

2017-08-14 17:29:42
yoku0825 @yoku0825

@surumegohan 永続化するのは良いんだけどどのタイミングで読み出すのかの資料がない気がするので聞いといてほしいです!

2017-08-14 18:02:23
しょー(show) @surumegohan

インデックスが使われない理由の例: インデックス列に計算したり関数を使用している。 LIKEの後方一致など。 #mysql_jp

2017-08-14 17:31:19
しょー(show) @surumegohan

Index Margeにあんまり過度な期待はしない方がよいです。。 #mysql_jp

2017-08-14 17:32:14
しょー(show) @surumegohan

最適化の種類によってパフォーマンスが異なる。 細かいロジックより、打ってみて確かめていく方がよいかもしれません。 #mysql_jp

2017-08-14 17:34:28
しょー(show) @surumegohan

セミナーおしまーい アンケートと入館バッチは提出忘れずに~ #mysql_jp

2017-08-14 17:35:31
NaruTo@うなぎ食べない教 @KAZAMAI_NaruTo

セミナー後に質問しました。 僕「Oracle の場合、Count(*) 使うな、Count(1) 使えと言いますが、 mysql はどうか?」 講師の人「主キーの列を指定するのがいい」 目から鱗が落ちました。 ありがとうございました。 #mysql_jp

2017-08-14 19:02:34

【20170816】

講師の方から補足訂正がありましたので追記しました。

Yoshiaki Yamasaki @yyamasaki1

@KAZAMAI_NaruTo すみません。考慮が漏れていたことがあったので、回答を訂正させて下さい。 訂正後の回答:count(*)を使用下さい。

2017-08-16 17:44:47
Yoshiaki Yamasaki @yyamasaki1

@KAZAMAI_NaruTo そして、先日の回答は以下の観点で"count(*)"に比べて良くないです。 ・主キーの指定という回答は、主キーが複合キーである場合にどのキーを指定すればいいか混乱を招く ・SQLの可読性が下がる("count(*)"であれば、件数をカウントしているSQLであることが一目で分かる)

2017-08-16 17:45:29
Yoshiaki Yamasaki @yyamasaki1

@KAZAMAI_NaruTo 補足です。 まず、"count(*)"はオプティマイザにより"count(0)"に変換されるため、count(*)とcount(1)の違いを気にする必要はありません。 ちなみに、変換後のSQLは、explain後にshow warningsで確認できます。(先日の資料のP70)

2017-08-16 17:45:04
Yoshiaki Yamasaki @yyamasaki1

@KAZAMAI_NaruTo 以下の記事で主キーより小さいsecondary index を指定することでcount(*)を早くする方法も紹介されていますが、次の観点で入門セミナーの回答としては「count(*)を使用下さい。」とさせて頂ければと思います。 nippondanji.blogspot.jp/2010/03/innodb…

2017-08-16 17:46:05
Yoshiaki Yamasaki @yyamasaki1

@KAZAMAI_NaruTo ・現行のオプティマイザであれば、count(*)指定でもsecondary index が使える場合はセsecondary index を選択してくれる可能性が高い ・secondary index を指定すると、SQLの可読性が下がる

2017-08-16 17:46:29
前へ 1 ・・ 6 7