MySQLのプロセスとメモリの構造について簡単にまとめてみました。
01 プロセス構造
サーバ本体: 'mysqld'というデーモンプロセス
- クライアントからの接続要求で内部にスレッドを生成して（スレッドキャッシュがない場合）、そのスレッドがクライアントのSQL文を処理する
MySQLサーバ・クライアント間プロトコル
- MySQL独自のプロトコルでデータ送受信する
セッション
- クライアントがバックエンドプロセスに接続してから切断するまでを1つと数える、通信の単位
- 対話型インターフェース mysql を起動してから（様々な処理をして）切断するまでが１つのセッション
02 メモリ構造
問い合わせ処理に関するバッファ群
| 配置 | バッファ | 説明 |
|---|---|---|
| 全スレッド共有 | key_buffer | インデックスデータを読み込んでスキャンするためのバッファ (MyISAM型テーブル専用) |
| read_buffer | インデックスが参照しているテーブルデータを読み込んでスキャンするためのバッファ | |
| スレッド毎 | read_md_buffer | テーブルデータを直接読み込んでランダムスキャンするためのバッファ |
| sort_buffer | 'ORDER BY'の処理など、結果の並べ替えに使うバッファ | |
| join_buffer | 複数のテーブルの完全結合を行うバッファ |
テーブルキャッシュ (table_open_cache)
- 多数のファイルに即座にアクセスするために、システムコール fopen() ではなく、'テーブルキャッシュ'に一度オープンしたファイルディスクリプタをキャッシュすることで、ファイルオープンのオーバーヘッドを削減する
通信バッファ (net_buffer)
- クライアントから受信するSQL文や、クライアントへ送信するデータの一時保管場所として使われる
- スレッド毎に確保される
- サイズは可変で、初期状態でシステム変数 net_buffer_length の値が確保され、データのサイズに応じてシステム変数 max_allowed_packet の値まで拡大される (送信後は初期値に戻る)
クエリキャッシュ (query_cache)
- 実行されたSELECT文の結果をキャッシュに保存しておき、同じSELECT文が要求された場合は検索を行わずにキャッシュに保存した結果を返す機能
スレッドキャッシュ
- 前節の通り
InnoDB型テーブル関連
- MySQLはInnoDB型テーブルの処理に関し、バッファプール (buffer_pool) を介してテーブルデータに読み書きする
参考文献
以前MySQLを「キャッシュのお化け」とする例え話を聞いたことがあるのですがなるほど今回の内容からだけでもその理由が分かりました。
