MySQL 5.7 初心者向けセミナー ~チューニング基礎編、SQLチューニング編~ 20170814
- surumegohan
- 3779
- 16
- 1
- 0
5.7から追加されたオプティマイザヒント。 構文をコメントとしてSQLに記載する。 構文が間違っててもコメントになるのでスルーされる点に注意 #mysql_jp
2017-08-14 17:17:54サブクエリだけ指定できるのでoptimizer_switchより細かい制御ができるようになる。 #mysql_jp
2017-08-14 17:18:33オプティマイザヒントはかなり突っ込んだチューニングになるので入門レベルではないです。。。 頭の片隅においておいてください。 #mysql_jp
2017-08-14 17:22:21オプティマイザヒントは8.0以降も今後改善計画がある。 新しいヒントの追加や既存ヒントのリプレースなど。 #mysql_jp
2017-08-14 17:23:30チューニングがうまくいかない場合は? → 商用版を契約しているならばチューニングに関する問い合わせもサポートします。スタンダードエディションでも。年間24万円。月当たり2万円です。詳細はMySQLコンサルティング・サポートをご参照ください #mysql_jp
2017-08-14 17:25:45オプティマイザ。4テーブルの場合でもJOINを順番に行う。2テーブルずつJOINするという動きはしない。 #mysql_jp
2017-08-14 17:27:10統計情報永続化。5.6から。5.5まではサーバ再起動すると統計情報を保存してませんでした。5.6以降の方が実行計画が安定する。サンプリングの精度をあげたければ、その方法も資料にあるので参考にしてください。 再計算を無効化することもできます。 #mysql_jp
2017-08-14 17:29:42@surumegohan 永続化するのは良いんだけどどのタイミングで読み出すのかの資料がない気がするので聞いといてほしいです!
2017-08-14 18:02:23インデックスが使われない理由の例: インデックス列に計算したり関数を使用している。 LIKEの後方一致など。 #mysql_jp
2017-08-14 17:31:19最適化の種類によってパフォーマンスが異なる。 細かいロジックより、打ってみて確かめていく方がよいかもしれません。 #mysql_jp
2017-08-14 17:34:28セミナー後に質問しました。 僕「Oracle の場合、Count(*) 使うな、Count(1) 使えと言いますが、 mysql はどうか?」 講師の人「主キーの列を指定するのがいい」 目から鱗が落ちました。 ありがとうございました。 #mysql_jp
2017-08-14 19:02:34【20170816】
講師の方から補足訂正がありましたので追記しました。
@KAZAMAI_NaruTo すみません。考慮が漏れていたことがあったので、回答を訂正させて下さい。 訂正後の回答:count(*)を使用下さい。
2017-08-16 17:44:47@KAZAMAI_NaruTo そして、先日の回答は以下の観点で"count(*)"に比べて良くないです。 ・主キーの指定という回答は、主キーが複合キーである場合にどのキーを指定すればいいか混乱を招く ・SQLの可読性が下がる("count(*)"であれば、件数をカウントしているSQLであることが一目で分かる)
2017-08-16 17:45:29@KAZAMAI_NaruTo 補足です。 まず、"count(*)"はオプティマイザにより"count(0)"に変換されるため、count(*)とcount(1)の違いを気にする必要はありません。 ちなみに、変換後のSQLは、explain後にshow warningsで確認できます。(先日の資料のP70)
2017-08-16 17:45:04@KAZAMAI_NaruTo 以下の記事で主キーより小さいsecondary index を指定することでcount(*)を早くする方法も紹介されていますが、次の観点で入門セミナーの回答としては「count(*)を使用下さい。」とさせて頂ければと思います。 nippondanji.blogspot.jp/2010/03/innodb…
2017-08-16 17:46:05@KAZAMAI_NaruTo ・現行のオプティマイザであれば、count(*)指定でもsecondary index が使える場合はセsecondary index を選択してくれる可能性が高い ・secondary index を指定すると、SQLの可読性が下がる
2017-08-16 17:46:29