1.MySQL論理アーキテクチャ
MySQLの学習を開始する前に、MySQLの基本的な論理アーキテクチャ図を描くことは、MySQLの学習に役立ちます。
以下は、「MySQL 45 Lectures」でLinXiaobin（画面名Ding Qi）によって提供されたMySQL論理アーキテクチャ図の変更結果です。キャッシュクエリ部分が削除されています（このモジュールはMySQL 8.0以降で削除されています）。
2.サーバーレイヤーコンポーネント
2.1。コネクタ
コネクタは、ほとんどのネットワークベースのクライアント/サーバーツールが持つアーキテクチャです。主にクライアント接続の確立、許可の取得、承認認証、接続管理を担当します。
クライアントはMySQLサーバーへの接続コマンドを開始します。MySQLサーバーは権限の検証（ユーザー名、パスワードなど）を実行します。検証が完了すると、サーバーは接続のスレッドを確立します。
接続が確立されると、コネクタはアクセス許可テーブルのアクセス許可を照会します。この時点でアクセス許可が決定されており、その後のアクセス許可の決定はこの時点でのアクセス許可に依存します。管理者アカウントがアクセス許可を変更しても、影響なし確立された接続のアクセス許可は、次に接続が再接続されるまで変更されます。
短い接続と長い接続
短い接続と長い接続をよく耳にします。本質的に、MySQLはこれらの2種類の接続を提供しません。これらの2種類の接続も、接続を維持する時間の長さに基づいて定義されます。
短い接続の実行プロセス：
長い接続の実行プロセス：
接続を維持することは、頻繁な承認検証、承認クエリなどによって引き起こされるパフォーマンスの低下を回避することです。ビジネスがデータベースと頻繁にやり取りする場合、接続が確立された後、接続プールに配置され、次の場合に取り出されます。必要です。使用してください。
1日に1回だけクエリを実行する必要がある場合（タスクのスケジュール設定など）、クエリの完了後、時間内に接続を切断します。これにより、アイドル状態の接続によるパフォーマンスの低下を減らすことができます。
アイドル接続
接続が確立された後、長期間使用されない場合、接続はスリープ状態になり、この時点でアイドル接続が生成されます。
次のコマンドを使用して、現在のリンクを表示できます。
show processlist;
現在、MySQLには3つのrootユーザー接続があり、そのうちID = 459の接続がアクティブです。他の2つの接続は、2つのアイドル接続であるスリープ状態になっています。
ID = 5のevent_schedulerによって維持される接続については、これがデーモンプロセスであることがデーモンからもわかります。event_scheduler、イベントスケジューラ、MySQL 5.1で追加された新機能で、オペレーティングシステムのタスクスケジューラでのみ実行できるスケジューリングタスクの一部を置き換えます。
自動的に切断
積極的に切断しないと、永遠に残りますか？
MySQLコネクタは、長期間使用されていない接続を自動的に切断します。この時間パラメータは、wait_timeoutによって決定されます。
次のコマンドを使用して、wait_timeoutを表示できます。
show variables like 'wait_timeout';
接続の最適化
MySQL接続の確立は複雑なプロセスです。接続を頻繁に作成すると、大量のメモリを消費します。
これは、実行中にMySQLが一時的に使用するメモリが接続オブジェクトで管理されているためです。これらのリソースは、接続が切断されると解放されます。長い接続が蓄積されると、メモリ使用量が多すぎて、システムによって強制的に強制終了される可能性があります。 Out（OOM）、現象の観点から、MySQLは異常に再起動します。– Lin Xiaobin、「MySQLの実際の戦闘に関する45の講義」
同時に、LinXiaobinは2つの提案をしました：
- アイドル状態の長い接続を定期的に切断し、接続を再確立してリソースを解放します。
- 大量のメモリを占有するクエリを実行した後、mysql_reset_connection（MySQL 5.7以降で提供されるコマンド）を使用して接続リソースをリセットします。このプロセスでは、再接続と再認証は必要ありませんが、接続は初期状態に復元されます。
2.2。アナライザー
MySQL 8.0より前は、MySQLはキャッシュクエリを提供していました。キャッシュがヒットしなかったSQLステートメントのみが分析-最適化-実行プロセスに入ります。ただし、データの場合、頻繁にクエリされるデータは通常頻繁に変更され、変更は頻度が低い。クエリの頻度が低いため、キャッシュのヒット率が非常に低い。MySQLの担当者もこれを認識しているため、MySQL 8.0ではキャッシュモジュールが削除されます（キャッシュを有効にしないため、削除します） 。
アナライザーは、SQLステートメントを解析し、内部データ構造を構築する（ツリーを解析する）ために使用されます。アナライザーは、字句アナライザーと構文アナライザーの2つの部分に分けることができます。
字句解析プログラムは、解析ツリーを構築するために使用されます。例えば：
select user_name from user;
パーサーの作業の下で、それは以下を認識します：
- select、queryステートメント;
- ユーザーから、クエリテーブルユーザー;
- user_name、列user_nameの値を取得します。
構文アナライザーは、入力SQLステートメントが正しいかどうかを検証するために使用されます。
通常、「SQL構文にエラーがあります」が検出され、構文パーサーによってプロンプトが表示されます。
2.3。オプティマイザー
アナライザーの作業が完了すると、オプティマイザーが次に動作します。オプティマイザーは主に、クエリの書き換え、テーブルの順序の読み取り、適切なインデックスの選択などを担当します。
通常、オプティマイザの後、MySQLは最適な実行プランを取得し（ただし、絶対ではありません）、エグゼキュータはSQLステートメントを実行します。
オプティマイザーがどのように決定を下すかを知りたい場合は、オプティマイザーに次のように説明するように依頼できます。
-- 表结构
CREATE TABLE `t_user` (
`user_id` bigint NOT NULL AUTO_INCREMENT,
`user_name` varchar(20) DEFAULT NULL,
`age` int DEFAULT NULL,
`gender` varchar(2) DEFAULT NULL,
`address` varchar(100) DEFAULT NULL,
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
-- 查看执行计划
explain select * from user where id = 1;
MySQLがオプティマイザによる最適化後に主キーの使用を選択したことがわかります（特定の実行プランは後で分析されます）。
ただし、オプティマイザの選択は、非常に低い確率で最適ではありません。実行プランを表示し、オプティマイザの選択を表示して、結果に応じてオプティマイザを再選択するように「導く」ことができます。
オプティマイザーは基盤となるストレージエンジンを気にしませんが、実際には、オプティマイザーの選択はストレージエンジンの影響を受けます。
オプティマイザーによる最適化の過程で、ストレージエンジンは、容量、操作オーバーヘッド、テーブルデータの統計情報などを提供するように要求されます。そして、オプティマイザーの選択ディメンションとして、SQLステートメントを最適化します。
2.4。アクチュエータ
アナライザーとオプティマイザーを体験した後、SQLステートメントを実行する時が来ました。
実行の開始時に、エグゼキュータはパーミッションを判断します。実行パーミッションがない場合、パーミッションなしのエラーを返します（MySQL 8.0より前では、クエリキャッシュもパーミッションを検証します）。
エグゼキュータは、ストレージエンジンのインターフェイスを呼び出すことにより、クエリ、変更、および削除を実現します。