MySQLのアーキテクチャについて調べる – スレッド編

Published: 2016年5月22日 by tomsato

概要

MySQLの内部のアーキテクチャについて気になったのでまとめる
どういうスレッドがあるのかとスレッドのライフサイクルについて記述する

スレッド、プロセスとは

MySQLはシングルプロセスマルチスレッドモデルを採用しており
1つのmysqldプロセスの内部に、複数のスレッドが存在している

そもそもプロセスとはプログラム(実行バイナリ)がOS上に実体を持ち、実行できる状態になったもので、プログラムがメモリにロードされて実行できる状態になったものをいう

スレッドはプロセスの中での実行単位

db01

簡単な例を出すとアプリケーションは劇場、プロセスは舞台、スレッドは役者という風に考えられる

ちなみに蛇足メモ
→ 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

■ コネクションをハンドルする時のライフサイクル

チューニングをする際に、どういう流れでデータを取得しているのかの流れを理解しておくとわかりやすい

db02

mysqldプロセスがclientから接続要求を受けると子プロセスをcloneしてそれがフォアグラウンドスレッドになる
認証や構文解析などを行った後、ストレージエンジンからデータを取得してデータを返却している

MySQLのチューニングを考えた時に一番処理に時間がかかっているのはエグゼキューターである
しかしそもそもオプティマイザが実行計画を作成していてその実行計画通りにエグゼキューターはストレージから取得しているだけである

実行計画が悪いとエグゼキューターの処理が遅くなる
つまりチューニングを考える際は実行計画を確認することが大事になる

実行計画を取得する方法は今回は割愛するが「EXPLAIN SELECT ~」を使って
・インデックスを使わないでテーブルを1行1行と全件検索していないか
・サブクエリの中にサブクエリを使っていてネストが深くなっていないか
などを確認する

※ 参考サイトから自分なりに噛み砕いてみましたが間違っていたらごめんなさい

参考

Share

最近の投稿

NetlifyのSplit TestingとFunctionsについて使い方をまとめる Split TestingはGitHubのブランチをベースにしたA/Bテストを行うための機能のことで、FunctionsはNetlifyでAWS Lambdaを使うことができる

NetlifyとはHTMLなどの静的コンテンツのみで構成されたWebサイトを閲覧できる形で配信するWebサービス GitHubやBitbucket、GitLabなどと連携して使うことができて、リポジトリにプッシュすることで自動でCI/CDを行うことができる、無料枠が豊富で独自ドメインを設定可能

WordPressからJekyll(GitHub Pages)に移行した手順をまとめる。 お金的な事情や使いやすさなどの理由で無料のJekyll+GitHub Pagesに移行した。JekyllとはMarkdown等から静的ページを生成する静的サイトジェネレータ

Scala開発のためにScalaらしさをまとめる 言語設計者の設計思想を元にScalaらしさについてまとめる オブジェクト指向と関数型の融合について

StorybookとはUI開発環境を提供するツール React、React Native、Angular、Vueなどをサポートしている ユーザーは独立した開発環境でコンポーネントを個別に作成して挙動の確認をテストできたり、コンポーネントを一覧にしてカタログ化できるので他の人に紹介する時に使えたりする

カテゴリ一覧

タグ一覧