「MySQL 5.7入門 SQLチューニング編」に行ってきた！ その２

５月３０日

【MySQLについてきちんと勉強したい方必見！】MySQL 5.7入門　SQLチューニング編
https://www-jp.mysql.com/news-and-events/events/mysql-for-beginners-sql-tuning-edition-ja/

に行ってきた！ので、その内容をメモメモのつづき（＝その１のつづき）

---

■ＭｙＳＱＬ５．７入門（ＳＱＬチューニング編）－　つづき

オプティマイザ詳細解説
・コストベースオプティマイザー
　　　　・論理的な変換
　　　　・準備
　　　　・コストベース最適化
　　　　・最終調整

　論理的変換
　　否定の除去
　　展開
　　定数式の評価
　　不要な条件の除去

　コスト
　リソース使用量
　単一クエリ＝関連性は考えない

　統計情報
　　５．５以前は統計情報は永続化されていない
　　analyze tableを実行

　コストの見積もり
　　コスト定数も変更できる
　　→最新のハードウェア

　パフォーマンススキーマから、ＩＯ速度調査できる

・アクセス方法の選択
　主キー、ユニークキー　constになる
　他　複数　ref

　Rangeスキャン
　　オプティマイザトレースで範囲確認できる
　　後方一致はインデックス使えない。

　インデックスマージ

　Handlerステータス変数について

　インデックス・コンデション・プッシュダウン


・ＪＯＩＮ
　Join順番の精度上がった
　小さいものから
　Visual Explainで確認
　あとのテーブルを評価してなかったけど、５．７ではそこも

・サブクエリー
　実は細かい話があるけど、内部的に勝手にされる話

・ソート処理、集計結果
　ファイルソートを避ける→インデックス
　リミット句
　内部的にソートが何回されたか

・集計クエリ
　参考情報として確認してね

・ＩＮに複数列
　最適化される

　クエリーリライトプラグイン
　　ＭｙＳＱＬサーバー側でクエリ書き換え

---

■ＳＱＬチューニングにも役立つ
　MySQL Enterprise Monitorのご紹介

・前のセッションで、大変そうだけど
　スローログ
　sys.statement_analysis
　イベントヒストリで確認することもできる

・これから紹介するのは
　複数台サーバーを包括的にする方法

・ファイルソート：ファイルとメモリ両方の場合
　スローログでわかりにくいもの

・自己紹介

・５．７　１０月　全文検索を高速、JSON
・ＤＢはコミュニティ版と商用版一緒

Enterprise Edition
・Enterprise Monitor
　アドバイスしてくれる機能

・問題が発生する前に通知

・ワークベンチとEnterprise Monitor
　　→ためられる

・ベストプラクティスアドバイザ
　　→パラメータあってるか、トライアルで確認する手も

・クエリアナライザー
　　なにで遅くなったか、解析できる
　　→スローログと比べて

・問題のあるクエリ実行プランを確認

・時系列パフォーマンスグラフ

・Ｉ／Ｏ大量発生
　　インデックスが最適化されていないケース
　　unused index

・Lock待ちの確認、プロセスの確認 show process List

・InnoDBバッファプールの利用状況

・レプリケーションモニター
　　トポロジーを見れる

（参考）Workbench
　→中期的には、Workbench以外も・・

技術サポート
・見つけた内容を、どうチューニングする？
　　→楽ではない
・物理サーバーごと
　　→仮想環境：パブリッククラウドについては営業に

・Oracle製品との連携
　　GoldenGate使える
　　EnterpriseManagerと統合できる

・セキュリティ対策

「MySQL 5.7入門 SQLチューニング編」に行ってきた！ その１

【MySQLについてきちんと勉強したい方必見！】MySQL 5.7入門　SQLチューニング編
https://www-jp.mysql.com/news-and-events/events/mysql-for-beginners-sql-tuning-edition-ja/

に行っている（今、受講中）！ので、その内容をメモメモ

---

資料のダウンロードＵＲＬ
http://www-jp.mysql.com/why-mysql/presentations/mysql-sqltuning-for-beginners-ja/
http://www-jp.mysql.com/why-mysql/presentations/mem-ja/

■ＭｙＳＱＬ５．７入門（ＳＱＬチューニング編）
・日本語に翻訳されたマニュアルは５．６しかない
　けど、５．７見てね（正規版は英語。翻訳は参考）

チューニングのアプローチ
　大きく２とおり
　　ＤＢ全体のチューニング：パラメータ変更
　　ＳＱＬのチューニング：ＳＱＬ最適化
　　　→性能格段に向上することは珍しくない

・ＳＱＬチューニングの流れ
　１．問題となるＳＱＬの特定
　２．実行計画やＳＱＬ実行時の稼働統計
　３．ＳＱＬチューニング実施
　　　　index、オプティマイザ、パラメータ、スキーマ変える・・・

ＳＱＬチューニングの基本
・１．問題となるＳＱＬの特定

　スロークエリログ
　　実行時間が指定した時間以上のクエリを出力する
　　デフォルトでは出力されない
　　　log-show-queries 秒単位で指定
　　　log-queries-not-using-index インデックス使っていないＳＱＬを出す

　　デフォルトはＯＳ上のファイル
　　loh-output　オプションでテーブルへも出力可能　
　　→出続けるので注意：運用時
　　　クエリの実行が終わってから出る：今時間がかかっているものには使えない
　　　　　→show full processlistを使う

　　たまり続けたファイルを集計する　mysqldumpslow
　　→MySQL Query Analyzer

　　MySQL workbenchからshow FULL PROCESSLISTを確認可能
　　　→コネクションの情報を見れる
　　　Visual explain
　　　コミュニティ版と商用版の両方がある

　パフォーマンス・スキーマ
　　性能統計情報分析のための仕組み
　　デフォルトで有効
　　sysスキーマ　MySQL5.7からデフォルト
　　　パフォーマンススキーマとインフォメーションスキーマをシンプルなビューに
　　　特に注目！statement_analysis,innodb_lock_waits
　　　トータル実行時間が長いＳＱＬ調査
　　→たまり続ける
　　　ロックまちＳＱＬの調査
　　まとめてtrancateする方法あり

　【商用版限定】MySQL Query analyzer
　　　クエリーレスポンスタイムインデックス
　　　初回実行時間
　　　グラフ→傾向が見える
　　　ＣＳＶファイルにもまとめられる

　【商用版限定】MySQL Enterprise Monitor
　　　MySQL Query analyzerはMySQL Enterprise Monitorの一部
　　　何かあったら伝えることができる

・２．実行計画やＳＱＬ実行時の稼働統計などの確認
　　実行計画：内部的処理の手順
　　ＳＱＬ：内部の処理手順は指定していない

　　オプティマイザが実行計画を作成
　　→同じＳＱＬでも実行計画が違えば、パフォーマンスが大きく異なる

　　オプティマイザー：最適化するモジュール
　　　最適な実行計画を作「ろう」とします
　　　　　コストベースのオプティマイザ
　　　　　　→コストを内部的に考える

・統計情報
　　コストベースオプティマイザのコストを見積もる時に
　　　　ベースとなる設定
　　　　統計情報
　　テーブル内のデータが１０％更新されたら再計算
　　　→なにもしてないのに遅くなることがあり得る

・EXPLAIN
　　実行計画の確認
　　　SQLの前にEXPLAIN と書くだけで使える
　　実行中のQUERYをコネクションＩＤでとれる
　→１７９ページ　パーティショニング機能
　　　論理的に区分けする

　拡張で追加取得
　　フィルタリング
　　show warning：オプティマイザが書き換えたＳＱＬ表示

　使用例
　　タイプがＡＬＬだったらチューニング候補

　select_type重要
　　　マテリアライズド
　　　union,subquery
　　特に注意；dependent,uncacheable 何回も実行してしまう可能性
　　　→相関サブクエリ
　　　出てきたら、要注意！
　　indexってでてきたら、あまりよくない

　Extra重要
　　一時テーブルをディスクに書いているとか
　　using filesort
　　
　構造化されたexplain
　　→JSON形式。情報量多い
　Visual Explain　色によってわかる
　オプティマイザトレース

　SHOW STATUS
　　sort_marge_passes：マージソートのパス数

　ワークベンチは、まとめて見れるようになっている
　　Query Statisticsから


３．ＳＱＬチューニング実施
・インデックスの活用
　　→大半を使うのであれば、インデックスを使わないほうが速いことも
　ＵＰＤＡＴＥでインデックスが使えていない場合には、
　　（ＩｎｎｏＤＢは行レベルになっているが）
　テーブルロックがかかってしまう→ロック待ちになる

・ＪＯＩＮの順番：内部的効率変わることがある
　　結果セットが少量になるテーブルからＪＯＩＮする　　
　　ＭｙＳＱＬは、ネステッドループジョイン：
　　　　１つの表から１件とってきて、２つめのテーブルから合うものを探す
　　　　　　１つめが少量のほうが、ループ回数少なくなる
　　　　　　２つめの表がインデックス使えたほうが、早く終わる
　　ブロックネステッドループ→ＪＯＩＮバッファのチューニング

・サブクエリ
　　５．６以降、かなり改善している
　　ＪＯＩＮ書き換えしなくてもパフォーマンスいいこと多い

・インデックスの考慮事項
　　つけすぎない：更新処理はオーバーヘッド
　　　重複するようなインデックス、
　　　取り得る値の種類が少ない場合
　　サイズの小さいインデックス：プレフィックス
　　複合インデックスを使った場合a,b
　　　b列に対しては、インデックス使えない（a列は使える）
　　→先頭の列から順番に
　　ユニークなものには、ユニークつける
　　　この一手間で違いがでる
　　マルチカラムインデックス
　　インデックスに処理をしない→関数インデックス、generated column

・インデックスマージ
　　５．０以降あり、５．６で緩和

・オプティマイザ制御
　　コスト調整５．７から
　　最適化アルゴリズム使う・使わない
　　ヒント使える

・ヒント
　インデックスヒント
　　　USE INDEX：使ってね,FORCE INDEX：絶対使え,IGNORE INDEX：使わないでね

　STRAIGHT_JOINヒント
　　　ＪＯＩＮの順番を指定（OUTER JOINでは使えない）

　オプティマイザヒント（５．７から）
　　　オプティマイザスイッチより細かい粒度で

・セミジョイン最適化　マテリアライズ

・optimizer_switch
　この前の対応をするのが基本。
　もっとのとき

・チューニングがうまくいかない時
　商用版はサポート範囲内

---

このあと、「オプティマイザ詳細解説」だけど、
ここまでで、十分長いので、いったん切る。

ついに明かされる「りんな」の“脳内”-MS 「女子高生AI」のアルゴリズム公開

ついに明かされる「りんな」の“脳内”　マイクロソフト、「女子高生AI」の自然言語処理アルゴリズムを公開
http://www.itmedia.co.jp/news/articles/1605/27/news110.html

（以下太字は上記サイトより引用）
あ～専門的にみると、突っ込みたくなる人もあるかとは思いますが、
我らが？太田智美さんが書いているので、温かい目でみてあげよう！


Microsoftが開発しているAIとして「Cortana」がよく引き合いに出されるが、Cortanaのコンセプトが「Productivity」（生産性向上）であるのに対し、りんなのコンセプトは「Emotional」（感情的）。例えば、「明日晴れるかなぁ？」という問い掛けに対し、Cortanaは「明日の天気は晴れです」と返すが、りんなは「どこか出かける予定でもあるの？」と、会話が進むための返事をする。


答えなくてもいい・・・この発想はなかったな・・・

IoTの開発手順－従来開発との違い

ＩｏＴが絡む案件は、以下のように開発していくのではないだろうか？

（１）目的の確認
・まず、何がしたいか、何を見たいかを確認する
・それを得るために
　　何を入力とし－入力データ
　　どう処理して－データ解析等
　　何を表現するか－アクチュエーター／可視化
　を決める

・ここで、
　　　・入力データを何らかの処理を行えば、出力データが得られる
　　　　　＝モデル化がされているのであれば。
　　　　そのモデルを明確にする

　　　・入力データと、出力データの関係が分からない場合は
　　　　　機械学習を行い、数理モデルを作成する

（２）入力、出力の具体化

　　　・入力データは、
　　　　　　　　いつ（９：００～１７；００とか。２４時間とか）
　　　　　　　　どこで（日本の農場とか、世界の山の上とか）
　　　　　　　　どれくらいの頻度で（３０分おきとか）
　　　　　　　　どれくらいの広がりで（１ｍおきに４０か所とか）
　　　　　　　　どんなセンサー等により（温度センサーとか）
　　　　収集し、
　　　・出力データは、
　　　　　　　　いつ（処理結果後すぐとか）
　　　　　　　　どこに（会社のオフィスで）
　　　　　　　　どのようなデバイスで（ディスプレイに
　　　　出力（表現）するか

　　を具体的に決める

（３）処理の具体化
　　　入力と出力、数理モデルから、
　　　どのくらいの計算が必要かを割り出し、
　　　どこで処理させるか（エッジかオンプレサーバーか、クラウドか、ハイブリッド？）
　　　を決める


（４）入出力インターフェースの決定（有線、無線？）

　　（２）の入出力から（３）の処理までの間、データをどう送るか、インターフェースを決める。

　　まず、有線で送るか、無線で送るか決める

　　　有線の場合は、伝送距離、伝送路（イーサネットケーブルなど）、伝送プロトコルなど
　　　無線の場合は、周波数、プロトコル等を決める

（５）システム構成を決定
　　（２）、（３）、（４）により、システムが描けるので、システム構成（ハード）を描く
　　無理はないか（センサーが電圧の割には、線が長すぎる、頻度の割にその周波数帯＆プロトコルは・・など）

（６）ユースケースごとのシナリオ
　　・初期設定時
　　・通常動作
　　・故障時
　（・点検時）
　について、それぞれのシナリオを（５）のシステム構成に基づき、具体的なストーリーにする

※ここまでできると、通用開発と変わらなく実施できる。
つまり、IoTの開発は、上記手順を必要とするところが従来開発と違う。
（（１）（２）は従来開発でも要求定義で似たところがあるので、具体的には
　　（３）～（６）が違う。）

とくに、（３）（４）（５）は従来設計とされていたところである。
だが、設計過程でこれを考えると、実際には遅く、手戻りが発生してしまう。
理由は（６）ユースケースが作れないから・・・

マスコミは、公平に報道しないと-沖縄女性殺害事件を悼むアメリカ人たちが謝罪の行列

放送法１条

第一条 　この法律は、次に掲げる原則に従つて、放送を公共の福祉に適合するように規律し、その健全な発達を図ることを目的とする。
一 　放送が国民に最大限に普及されて、その効用をもたらすことを保障すること。
二 　放送の不偏不党、真実及び自律を保障することによつて、放送による表現の自由を確保すること。
三 　放送に携わる者の職責を明らかにすることによつて、放送が健全な民主主義の発達に資するようにすること。


偏った報道をしてはいけません。ですから、沖縄に関しても

沖縄女性殺害事件を悼むアメリカ人たちが謝罪の行列を形成　→マスコミ・基地反対派は当然のようにスル―
http://blog.esuteru.com/archives/8594594.html

とか

沖縄の路上、炎天下の中で見られた光景に考えさせられる 6枚
http://buzzmag.jp/archives/62493

も報道しないと・・・