概要
MySQLの内部のアーキテクチャについて気になったのでまとめる
どういうスレッドがあるのかとスレッドのライフサイクルについて記述する
スレッド、プロセスとは
MySQLはシングルプロセスマルチスレッドモデルを採用しており
1つのmysqldプロセスの内部に、複数のスレッドが存在している
そもそもプロセスとはプログラム(実行バイナリ)がOS上に実体を持ち、実行できる状態になったもので、プログラムがメモリにロードされて実行できる状態になったものをいう
スレッドはプロセスの中での実行単位
簡単な例を出すとアプリケーションは劇場、プロセスは舞台、スレッドは役者という風に考えられる
ちなみに蛇足メモ
→ MySQLが使用する最大メモリ = グローバルバッファ + max_connections × スレッドバッファの合計値
MySQLのスレッドについて
大きく分けてフォアグラウンドスレッド、バックグラウンドスレッドの2種類のスレッドが存在している
それぞれの中にも多数のスレッドがあってスレッドによって役割が異なる
多数のスレッドがそれぞれの役割を果たすことによってMySQLというアプリケーションができあがる
フォアグラウンドスレッド
1コネクションあたり1つのフォアグラウンドスレッドを起動しておりMySQLのほとんどのスレッドはフォアグラウンドスレッドで占有している
レプリケーション関連のスレッドもフォアグラウンドスレッドである
バックグラウンドスレッド
バックグラウンドスレッドの多くはInnoDBの非同期スレッド
https://dev.mysql.com/doc/refman/5.6/ja/innodb-performance-multiple_io_threads.html
■ コネクションをハンドルする時のライフサイクル
チューニングをする際に、どういう流れでデータを取得しているのかの流れを理解しておくとわかりやすい
mysqldプロセスがclientから接続要求を受けると子プロセスをcloneしてそれがフォアグラウンドスレッドになる
認証や構文解析などを行った後、ストレージエンジンからデータを取得してデータを返却している
MySQLのチューニングを考えた時に一番処理に時間がかかっているのはエグゼキューターである
しかしそもそもオプティマイザが実行計画を作成していてその実行計画通りにエグゼキューターはストレージから取得しているだけである
実行計画が悪いとエグゼキューターの処理が遅くなる
つまりチューニングを考える際は実行計画を確認することが大事になる
実行計画を取得する方法は今回は割愛するが「EXPLAIN SELECT ~」を使って
・インデックスを使わないでテーブルを1行1行と全件検索していないか
・サブクエリの中にサブクエリを使っていてネストが深くなっていないか
などを確認する
※ 参考サイトから自分なりに噛み砕いてみましたが間違っていたらごめんなさい
コメントを書く
コメント一覧