接続が確立されたら、select ステートメントを実行できます。実行ロジックは最初にキャッシュ モジュールに来ます。
キャッシュ
MySQL はクエリ リクエストを取得すると、まずクエリ キャッシュに移動して、このステートメントが以前に実行されたかどうかを確認します。以前に実行されたステートメントとその結果は、キーと値のペアの形式でメモリに保存されます。キーはクエリ ステートメントであり、値はクエリ結果です。クエリがこのキャッシュ内でキー (ヒット) を直接見つけることができた場合、値はクライアントに直接返されます。
キャッシュにミスがある場合、後続の実行フェーズが続行されます。実行が完了すると、実行結果はクエリ キャッシュに保存されます。ここでわかるように、クエリがキャッシュにヒットすると、MySQL は後続の複雑な操作を実行せずに結果を直接返すことができ、非常に効率的です。
しかし、ほとんどの場合、クエリ キャッシュを使用しないことをお勧めします。なぜでしょうか?クエリ キャッシュは多くの場合、良いことよりも害を及ぼすためです。
クエリ キャッシュは非常に頻繁に失敗します。テーブル内の特定のデータが更新される限り、このテーブル上のすべてのクエリ キャッシュはクリアされます。
したがって、結果を保存するのは非常に難しいかもしれませんが、結果は使用される前に、アップデートによって完全に消去されます。更新圧力が高いデータベースの場合、クエリ キャッシュのヒット率は非常に低くなります。あなたのビジネスに、長い間 1 回しか更新されない静的なテーブルがある場合を除きます。
例: システム構成テーブルの場合、このテーブルのクエリはクエリ キャッシュに適しています。
幸いにもMySQLは、この「オンデマンドで使用する」方法も提供します。パラメータ query_cache_type を DEMAND に設定すると、クエリ キャッシュがデフォルトの SQL ステートメントに使用されなくなります。
「注意」:MySQL 8.0 バージョンでは、クエリ キャッシュ機能全体が直接削除され、キャッシュ機能がまったくない MySQL 8.0 が始まりました。
パーサー
クエリ キャッシュがヒットしない場合、ステートメントの実際の実行が開始されます。まず、MySQL はユーザーが何をしたいのかを知る必要があるため、SQL ステートメントを解析する必要があります。
アナライザーは最初に「字句解析」を行います。入力するのは複数の文字列とスペースで構成される SQL ステートメントであり、MySQL はその中の文字列が何であり、それが何を表しているのかを識別する必要があります。
字句解析が完了したら、次は「文法解析」を行う必要があります。字句解析の結果に基づいて、構文アナライザーは、入力された SQL ステートメントが文法規則に基づいた MySQL 構文を満たすかどうかを判断します。
SQL を入力するときに文字が抜けていたり、スペルが間違っていたりすると、「SQL 構文にエラーがあります 」というエラー メッセージが表示されます。
たとえば、次の場合:
エラーは、WHERE に E が欠落していることです。キーワード。
同様に、フィールドが存在しない場合は SQL を使用します。
通常、文法エラーがあると、エラーが発生した最初の位置が表示されるため、「use」の直後の単語に注意する必要があります。この内容は参考用です。このヒントはあまり信頼できない場合があります。
SQL はアナライザーによって分析されましたが、エラーは報告されませんでした。次に、この時点でオプティマイザを入力して SQL を最適化します。
オプティマイザー
オプティマイザーは主に、データベース テーブルに複数のインデックスがある場合、またはステートメントに複数のインデックスがある場合に、どれを使用するかを決定します。複数のテーブルの関連付け (結合) により、各テーブルの接続順序が決まります。
例:
SELECT a.id, b.id FROM t_user a join t_user_detail b WHERE a.id=b.user_id and a.user_name='田维常' and b.id=10001
条件付きクエリを最適化します。
オプティマイザの処理が完了すると、SQL の実行計画が決定されます。次にアクチュエーターに進みます。
Executor
まず、権限、つまり、この SQL を実行する権限があるかどうかを判断する必要があります。作業中に一部のクライアントで権限が制御される場合があります。
例: 運用環境では、ほとんどの開発者はクエリ権限のみを持ち、追加、削除、変更の権限を持ちません (一部の小規模企業を除く)。
#権限がある場合は、テーブルを開いて実行を続行します。テーブルが開かれると、エグゼキューターはテーブルのエンジン定義に基づいてエンジンによって提供されるインターフェイスを使用します。
#ストレージ エンジン層
この層では、これは、ビジネス システムの永続層として理解できます。 ストレージ エンジンの概念は MySQL に固有のものであり、すべてのリレーショナル データベースにストレージ エンジンの概念があるわけではありません。
データベース ストレージ エンジンはデータベースの基盤となるソフトウェア組織であり、データベース管理システム (DBMS) はデータ エンジンを使用してデータの作成、クエリ、更新、削除を行います。異なるストレージ エンジンは、異なるストレージ メカニズム、インデックス作成手法、ロック レベル、その他の機能を提供しており、異なるストレージ エンジンを使用して特定の機能を取得することもできます。現在、多くの異なるデータベース管理システムが、さまざまなデータ エンジンをサポートしています。
リレーショナル データベースではデータがテーブルの形式で格納されるため、ストレージ エンジンはテーブル タイプ (テーブル タイプ、つまり、このテーブルのストレージと操作のタイプ) と呼ばれることもあります。
MySQL5.5 バージョン (mysql バージョン MySQL5.5 バージョン (mysql バージョン >= 5.5 バージョン) 今後、デフォルトのストレージ エンジンは InnoDB になります。 以下は、比較的一般的に使用されるいくつかのエンジンの比較です:
In In実際のプロジェクトでは、ほとんどが InnoDB を使用し、次に MyISAM を使用し、少なくとも他のストレージ エンジンが使用されます。 コマンドを使用して、MySQL が提供しているストレージ エンジンを確認できます:
show engies;
また、 MySQL の現在のデフォルトのストレージ エンジンを表示するには、コマンドを使用します:
'%storage_engine%' などの変数を表示します。
##MyISAM および InnoDBエンジンの違い
MySQLバージョン 5.5 より前のデフォルトのストレージ エンジンは、MyISAM ストレージ エンジンです。MySQL の多くのシステム テーブルは、MyISAM ストレージ エンジンとシステム一時テーブルを使用します。 MyISAM ストレージ エンジンも使用されますが、Mysql5.5 以降、デフォルトのストレージ エンジンは InnoDB ストレージ エンジンです。
#2 つのストレージ エンジンのどちらを選択すればよいですか?
#トランザクション操作はありますか?はい、InnoDBです。 同時変更を保存しますか?はい、InnoDBです。 -
#データ変更を少なくして高速なクエリを追求していますか?はい、MyISAM。
-
フルテキスト インデックスを使用しますか?サードパーティのフレームワークを参照しない場合は、MyISAM を選択できますが、サードパーティのフレームワークと InnDB を使用する方が効率的です。
#InnoDB ストレージ エンジンには主に次の機能があります:
トランザクションのサポート
-
#マルチバージョン読み取りをサポート
-
##行レベルのロックをサポート
読み取りおよび書き込みのブロックはトランザクション分離レベルに関連します
-
#インデックスとデータの両方をキャッシュできるキャッシュのサポート
# #全体テーブルと主キーはクラスター モードで保存され、バランスの取れたツリーを形成します
# もちろん、これは InnoDB が必ずしも優れているという意味ではありません実際の開発では、特定のシナリオに基づいて InnoDB と MyISAM のどちらを使用するかを選択する必要があります。
#MyIASM (このエンジンは、5.5 より前の MySQL データベースのデフォルトのストレージ エンジンです) 機能:
##MyISAM はデータベース トランザクションをサポートしていません
行レベルのロックと外部ロックをサポートしていませんキー
2 により、INSERT 挿入または UPDATE 更新ステートメントを実行するとき、つまりテーブル全体をロックする必要があります。書き込み操作を実行するため、効率が低下します。
MyISAM はテーブル内の行数を保存します。 SELECT COUNT(*) FROM TABLE を使用すると、テーブル全体をスキャンせずに関連する値を直接読み取ることができ、高速です。
MyISAM は非トランザクション的に安全ですが、InnoDB はトランザクション的に安全です
#
MyISAM はフルテキスト インデックスをサポートしますが、InnoDB は MySQL5.6 より前のフルテキスト インデックスをサポートしません。MySQL5.6 以降は FULLTEXT インデックスをサポートします。
#使用シナリオの比較:
多数の選択操作を実行したい場合は、MyISAM を選択してください
##多数の選択操作を実行したい場合は、MyISAM を選択してください。挿入および更新操作の場合は、InnoDB を選択する必要があります
大規模なデータ セットでは、トランザクション処理とエラーをサポートするため、InnoDB エンジンが選択される傾向があります。回復。データベースのサイズによって障害回復時間の長さが決まります。InnoDB はデータ回復にトランザクション ログを使用できるため、より高速です。 InnoDB エンジンでは主キー クエリも非常に高速になりますが、主キーが長すぎるとパフォーマンスの問題が発生することに注意してください。
比較的、InnoDB はインターネット企業によって多く使用されています。 #システム ファイル ストレージ レイヤー
##これはオンです最初のレベルは、ビジネス システムのデータベースとして理解することもできます。
システム ファイル ストレージ レイヤーは、主にデータベース データとログをシステム ファイルに保存し、同時にストレージ エンジンとのトランザクションを完了する役割を担っており、ファイルの物理ストレージ レイヤーです。 例: データ ファイル、ログ ファイル、pid ファイル、構成ファイルなど。
データ ファイル
「db.opt ファイル」: このデータベース テストのデフォルトの文字セットと調整を記録します。ルール。
「frmファイル」: エッジに格納されるテーブル構造の定義情報などのメタデータ情報。各テーブルに対応するfrmファイルが存在します。
「MYD ファイル」: MyISAM テーブルのデータ情報を格納する MyISAM ストレージ エンジン専用のファイルで、各 MyISAM テーブルには .MYD ファイルがあります。
「MYI文件」：也是MyISAM存储引擎专用的文件，存放MyISAM表的索引相关信息，每一张MyISAM表都有对应的.MYI文件。
「ibd文件和ibdata文件」：存放InnoDB的数据文件（包括索引）。InnoDB存储引擎有两种表空间方式：独立表空间和共享表空间。
- 独享表空间使用ibd文件来存放数据，并且每一张InnoDB表存在与之对应的.ibd文件。
- 共享表空间使用ibdata文件，所有表共同使用一个或者多个.ibdata文件。
「ibdata1文件」：系统表空间数据文件，存储表元数据、Undo日志等。
「ib_logfile0、ib_logfile0文件」：Redo log日志文件。
日志文件
错误日志：默认是开启状态，可以通过命令查看：
show variables like '%log_error%';
二进制日志binary log：记录了对MySQL数据库执行的更改操作，并且记录了语句的发生时间、执行耗时；但是不记录查询select、show等不修改数据的SQL。主要用于数据库恢复和数据库主从复制。也是大家常说的binlog日志。
show variables like '%log_log%';//查看是否开启binlog日志记录。
show variables like '%binllog%';//查看参数
show binary logs;//查看日志文件
慢查询日志：记录查询数据库超时的所有SQL，默认是10秒。
show variables like '%slow_query%'；//查看是否开启慢查询日志记录。
show variables '%long_query_time%'；//查看时长
通用查询日志：记录一般查询语句；
show variables like '%general%'；
配置文件
用于存放MySQL所有的配置信息的文件，比如：my.cnf、my.ini等。
「pid文件」
pid文件是mysqld应用程序在Linux或者Unix操作系统下的一个进程文件，和许多其他Linux或者Unix服务端程序一样，该文件放着自己的进程id。
「socket文件」
socket文件也是Linux和Unix操作系统下才有的，用户在Linux和Unix操作系统下客户端连接可以不通过TCP/IP网络而直接使用Unix socket来连接MySQL数据库。
SQL查询流程图
概要
MySQL システム全体は、私たちが毎日開発するソフトウェア システムと考えることができます。また、外部クライアントに接続するために特別に設計されたアクセス層もあります。これは、システムのゲートウェイに非常によく似ています。キャッシュは、次のようなものです。ビジネスコードで使用されるキャッシュ 分析 プロセッサはビジネスシステムにおけるパラメータ解析とパラメータ検証として理解できます 最適化層はコード開発を最適化する手段として使用できます その場合、ストレージエンジンは永続化層に相当しますであり、ファイルシステムは業務システム全体におけるデータベースに相当します。
例えがあまり適切ではないかもしれませんが、重大度の意味を理解していただければ幸いです。目的はただ 1 つ、誰もが MySQL## の全体的な状況を簡単に把握できるようにすることです。 ＃。
記事内の一部の写真はインターネットからのもので、削除されました。
偉大な人々や偉大な神々を毎日羨ましく思う必要はありません。彼らもまた、一歩ずつ前進してきたのです。自信を持ってください。少しずつ、地道に取り組んでいけば、きっと素晴らしい達人になれるでしょう。
#推奨読書
##あなたが動かないなら、私は動かないt move- --オブザーバーパターン
