Zenn
📈

MySQL High Performance Tuning Guide in Udemy Section 1

2022/12/25に公開
MySQL
Udemy
tech

MySQL High Performance Tuning Guide in Udemy Section 1

仕事でMySQLでクエリのパフォーマンスチューニングをやる必要がある場面があるのだが、いつも実行計画の見方や考え方のコツをその時々で掴んでは次の場面で忘れてしまう。おそらく体系的な勉強もパフォーマンスチューニングの素振りも足りてないのだと感じ、良いものがないか探していた。結果、このUdemyのコースが実際に動かせる例も豊富で体系的な説明も豊富そうだったので、まとまった時間の取れるこの年末にやってみる。

https://www.udemy.com/share/1055DK3@mpSRE-O7rzKdh7whaoNKpw5HA2xoI_up10M29L-_6epj_NOz0jLdCRi07ePA_Qoreg==/

会社で「SQLパフォーマンスチューニング100本ノックがほしいよね」と話したところ、「10本ノックでいいからほしい」という話になったので、この教材がそういうものとして使えるかどうか確認してみたい。

この記事では僕の個人的な勉強のメモをそのまま載せます。もしこのコースに興味があるひとがいたら、ざっと眺めてどのような知識が得られるのか判断できる材料のひとつくらいにはなるといいかなと思います。このコースの作者はルーマニアのエンジニアで10年以上経験のあるひとのようです。英語は若干なまってるけど、ゆっくり話してくれるし、他のコースに比べると聞き取りやすい英語だと感じました。字幕は自動生成だから専門用語が不正確だけど(MySQLとかInnoDBとか)、それ以外はほぼ正確なので問題ないと思いました。

全部で9セクションあり、今回はSection 1の部分について。

1. Query Execution Basics

  • MySQLのもっとも重要な特徴は、ストレージエンジンがクエリプロセシングや他の処理から分離されていること

英語

  • architectural characteristics
    • アーキテクチャの特徴
  • redundant systems
    • 冗長化されたシステム
  • retrieval
    • 検索
  • prior to MySQL version eight
    • MySQL version 8 以前では

2. Utiliity layer

  • MySQLにはフローコントロールがない

フロー制御とは、データ通信において、受信側の処理が追いつかずにデータを取りこぼしたりするのを防ぐため、通信状況に応じて送信停止や速度制限などの調整を行う機能のこと
https://e-words.jp/w/フロー制御.html

  • クライアントはメッセージを送ったら、サーバーはメッセージの全体を受け取ってから応答しなければならない
    • フローコントロールがあれば、メッセージの全体ではなく、ちょっとずつメッセージを送りながら、受信側で受け取れるかどうか確認しながらやるのかな？
  • MySQLサーバーは、全ての行を処理し終えるまでログを吐かないし、クエリに必要なリソースも開放しない
  • クライアントライブラリのデフォルトの挙動はインメモリなバッファにサーバーレスポンスをためる。しかし、大容量のデータを扱う場合はメモリを食うので、ライブラリにバッファを使わないように教える必要がある。しかしこの場合は、アプリケーションがサーバーとやり取りしている間は、ログも吐かないしリソースも開放しないことが欠点。

英語

  • need to disservices
    • ひどい仕打ちが必要だ
      • たぶん「たいへんな実装がいるんだよねー」という感じ
  • we should be aware
    • 知っている必要がある
  • be in ascending data state
    • 昇順のデータになっている
  • the downside is that ...
    • 欠点は…

3. SQL Layer

  • Optimizerはクエリの実行方法を複数持っていて、実行コストを推測し、最適な実行方法を決める
  • 実行コストは統計情報に基づいている
  • 統計情報はテーブル、インデックス、インデックスのカーディナリティ、行やキーの長さなど
  • 統計情報は間違うので、Optimizerはいつでもベストプランを選べるわけではない
  • 統計情報はストレージエンジンに依存しているが、InnoDBは行やテーブルの集約値をメンテナンスしていない
  • 理由はMVCCアーキテクチャーによるものだが、それは後で説明する
  • 実行コストは実際に実行するときの真のコストと一致しない
  • 理由は、MySQLはIOのコストまでわからないから
  • MySQLのポジティブな面はJOINやsubqueryの最適化などたくさんある

英語

  • any functionality provided across storage engine
    • ストレージエンジンを通して提供されるあらゆる機能
  • nonetheless
    • それでもやはり
  • as mentioned
    • 述べたように

4. Storage Engine Layer

  • ストレージエンジンはプラグインとして実装されていて、データ処理方法の変更を簡単にしている
  • InnoDBはフルトランザクショナルで高い並行性をサポートしていて、特に理由がなければInnoDB以外のエンジンを使うことはあまりない
  • Optimizerはテーブルがどのストレージエンジンを使っているかを気にしないが、ストレージエンジンはクエリの最適化方法に影響を与える
  • OptimizerはストレージエンジンのAPI経由で統計情報を受け取るから

5. Conclusion

セクション1まとめ。特に新しい情報はなし。

GitHubで編集を提案

Discussion