MySQLはリレーショナルデータベースです。名前が示すように、リレーショナルモデルに基づくデータベースです。現実世界のさまざまなエンティティやエンティティ間のさまざまな接続は、通常、リレーショナルモデルで表すことができます。数十年の開発の後、リレーショナルデータベースは理論と産業慣行の両方で非常に成熟したレベルに発展しました。現在のアプリケーションのほとんどは、MySQLを使用した成熟したソリューションを備えていると言えます。
データベースのアーキテクチャは、一般的にアプリケーション層、論理層、物理層に分けることができ、MySQLもこのように理解できます。
Mysqlに対応：
クライアントとユーザーとの対話を担当するアプリケーション層は、さまざまなクライアントと中間サーバーとの対話、接続の確立、接続のステータスの記憶、要求への応答、データと制御情報（エラーメッセージ、ステータスコードなど）を返す必要があります。 ）。
ロジックレイヤーは、特定のクエリ処理、トランザクション管理、ストレージ管理、リカバリ管理、およびその他の追加機能を担当します。クエリプロセッサは、クエリの解析と実行を担当します。クライアントからSQLクエリを受信すると、データベースはそれを処理するスレッドを割り当てます。クエリプロセッサは、実行プランを生成し、実行のためにプランエグゼキュータに渡します。実行者にもアクセスする必要があります。下位レベルのトランザクションストレージマネージャーがデータを操作します。トランザクションおよびストレージマネージャーは、主にトランザクション管理、同時実行制御、およびストレージ管理を担当します。トランザクションマネージャーは、「ACID」機能とロックマネージャーは同時実行性を制御します。ログマネージャーはデータの永続性を保証し、ストレージマネージャーには通常、ディスクバッファーとメモリバッファー間のデータ転送を決定するバッファーマネージャーも含まれます。
物理層、実際の物理ディスク（ストレージ）上のデータベースファイル。データファイル、ログファイルなど。
最初に、Mysqlが提供する公式のインフラストラクチャ図を見ることができます。
Mysqlの簡略化された論理アーキテクチャ図を見てみましょう。
図からわかるように、論理レベルでは、サーバー層とストレージエンジン層の2つの部分に大別できます。
サーバーレイヤーには、主にコネクタ、アナライザー、オプティマイザー、エグゼキューター、クエリキャッシュなどが含まれます。MYSQLのコア関数のほとんどと、すべての組み込み関数（日付、時刻、数学、暗号化関数など）をカバーし、ストアドプロシージャなど、すべてのクロスストレージエンジン関数がこのレイヤーに実装されます。 、トリガー、ビューなど。
ストレージエンジン層は、データの保存と取得を担当します。そのアーキテクチャモードはプラグインであり、InnoDB、MyISAM、メモリなどの複数のストレージエンジンをサポートします。今日最も一般的に使用されているストレージエンジンはInnoDBであり、MySQL5.5.5以降のデフォルトのストレージエンジンです。
異なるストレージエンジンがサーバーレイヤーを共有します
- コネクタ
コネクタは主に、接続、権限の確立、クライアントとの接続の維持と管理を担当します。
mysql -h$ip -P$port -u$username -p$password
MYSQLコネクタが接続を確立した後、現在のユーザーの権限を変更しても、現在の接続には影響しません。接続が切断された後、再接続後に権限の検証が再度実行されます。接続が完了した後は、アイドル接続と呼ばれるフォローアップ操作はありません。次に示すように、showprocesslistコマンドを使用してアイドル接続を照会できます。
MYSQLのデフォルトの接続時間は8時間で、wait_timeoutパラメーターで制御できます。接続の確立は非常に複雑なプロセスであるため、長い接続方法を使用することをお勧めします。mysqlの実行中、メモリ管理は接続オブジェクトで一時的に使用され、切断後にのみ解放されます。接続が長期間維持されると、OOMが発生する可能性があります。解決策は次のとおりです。
1. 定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再重连。
2. 如果你用的是 MySQL 5.7 或更新版本，可以在每次执行一个比较大的操作后，通过执行 mysql_reset_connection 来重新初始化连接资源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。
复制代码- クエリキャッシュ
mysql8バージョンより前は、クエリキャッシュモジュールがあり、各クエリ結果はクエリキャッシュにキャッシュされていました。次回は、同じSQLが直接キャッシュに移動して結果を返します。通常、デフォルトのクエリステートメントはキャッシュはテーブル用であるため、キャッシュを使用します。変更すると、このテーブルのすべてのキャッシュが削除されます。デフォルトではキャッシュを使用せず、必要に応じてキャッシュを使用するように、次のパラメータを構成できます。
query_cache_type 设置为 DEMAND
select SQL_CACHE * from T where ID=10；//SQL_CACHE 显示指定当前sql走缓存
复制代码- アナライザ
mysqlアナライザは、sqlステートメントを逆アセンブルすることにより、select、update、delete、およびinsertを判断し、対応するテーブルとwhere条件をfromから逆アセンブルします。分解して、現在のsqlステートメントがmysql仕様に準拠しているかどうかを確認します。標準化されていない場合は、「SQL構文にエラーがあります」というエラーメッセージがスローされます。
- オプティマイザ
mysqlオプティマイザは、次のように、現在のSQLに複数のインデックスがある場合に移動するインデックスを決定します。
select * from a join b useing(ID) where a_id = 1;
复制代码オプティマイザは、関連付けによって2つのテーブルを比較します。テーブルaのデータのテーブルbのデータが少ない場合、オプティマイザはテーブルaをメインテーブルとして使用してテーブルbを関連付け、クエリの数はその回数よりもはるかに少なくなります。テーブルbはテーブルaに関連付けられています。クエリ結果は同じですが、実行効率が異なります。オプティマイザが最適なソリューションを選択します。ここで、MySQLが左端の原則、インデックスカバレッジ、インデックスプッシュダウンなどを最適化するとよく言われます。 Explainを介してSQL実行計画をチェックし、インデックスを使用するかどうかを決定できます。
- アクチュエータ
mysqlエグゼキュータは、SQLが実際に実行される場所です。最初に、実行権限があるかどうかを判断するために権限チェックが実行されます。次に、インデックスがあるかどうかの2つのケースがあります。
select * from a where ID = 1;
复制代码IDフィールドにインデックスがある場合、条件に従ってインデックスツリーを通過するインデックスがあり、インデックスツリーをすばやくトラバースしてインデックスにヒットします。主キーインデックスはデータを直接クエリして結果セットに保存し、次の実行を続行します。セットは、インデックスツリーをトラバースした後、結果セットをクライアントに返します。
IDフィールドにインデックスがない場合は、innodbエンジンインターフェイスを呼び出してテーブルの最初の行をフェッチし、条件を満たしているかどうかを判断します。テーブル内のすべての行が表示されるまで、インターフェイスを呼び出して次の行をクエリし続けないでください。トラバースされ、クエリ結果が結果セットに配置され、クライアントに返されます
まとめ：
この記事では、mysqlインフラストラクチャを紹介し、論理アーキテクチャに焦点を当てます。これにより、mysqlでクエリステートメントが実行される順序がわかり、mysql実行プロセスの予備的な印象を得ることができます。引き続きmysql実行を分解します。ステップバイステップで詳細に処理します。
参照：
知乎zhuanlan.zhihu.com/p/19965157
オタク時間mysql戦闘45講義