MySQL アーキテクチャ
接続層
クライアントおよびプログラムとの接続と認証の確立を担当します...
サービス層
SQLインターフェイスパーサークエリオプティマイザーキャッシュ
エンジン層
データ ファイル システムへの接続とデータの書き込みを担当します。
物理ファイル層
ログに依存するテーブル データとログ ファイルの保存を担当します。
MySQLストレージエンジン
エンジンはデータベース内のファイルと特に対話するテクノロジーであり、エンジンの実装方法が異なれば異なります。
データベース エンジン、特定の実装者
一般的に使用されるエンジン
Myisam はトランザクションをサポートせず、多くのクエリに適しています。外部キー、行ロック、テーブル ロック、フルテキスト インデックスをサポートし、テーブル内の総行数を保存します。
admin から select count(*) を使用すると、合計行数を直接取得でき、高速です。
innodb はトランザクションをサポートし、追加、削除、変更に適しており、トランザクション、テーブル ロック、行ロックをサポート、キャッシュをサポート、主キーの自動インクリメントをサポート、フルテキスト インデックスをサポートし、テーブル内の総行数は保存しません。
select count(*) from admin 自己計算が遅い
データベースでサポートされているエンジンをクエリするには、このステートメントをデータベースに入力します。
show engines
索引
配列インデックスは、インデックスを通じて特定の場所にあるデータをすばやく検索できます。
なぜインデックスがあるのでしょうか?
インデックスを使用しない場合、クエリは最初の行から開始され、必要なデータが見つかるまで 1 行ずつ逆方向に検索されるため、データ量が多くない場合、クエリ効率は比較的低くなります。
インデックスとは何ですか
インデックスは、MySQL がデータを効率的に取得するのに役立つデータ構造です。
高速検索のためのソートされたデータ構造
検索を容易にするためにデータをデータ構造に維持します
インデックスの原理
インデックスは書籍のカタログに似ており、カタログを通じてデータをすばやくクエリし、クエリの範囲を絞り込むことができます。
インデックス作成の利点
データ検索の効率を向上させ、データベースの IO コストを削減します。
インデックス列を介してデータを並べ替えると、データの並べ替えコストが削減され、CPU 消費量が削減されます。
インデックス作成のデメリット
メモリ容量も必要
テーブルに対して追加、変更、削除の操作を行う場合、データの操作と同時にインデックス情報も変更する必要があります。
インデックス作成の原則
インデックスは優れていますが、むやみに使用しないでください
インデックスが必要になるのはどのような場合ですか?
主キーは一意のインデックス、主キーインデックスを自動的に作成します
クエリ条件として使用される列はインデックスの作成に適しています
外部キーのインデックスを作成することをお勧めします
フィールドの並べ替えとグループ化はインデックスの追加に適しています
インデックスの使用が推奨されないのはどのような場合ですか?
テーブルレコードが少なすぎます
頻繁に使用するテーブルを追加、変更、削除し、元のテーブルを別のテーブルに分割して、読み取りと書き込みを分離します。
クエリ条件ではありません
データは繰り返され、均等に分散されます。例: 性別
指数の分類
主キーインデックス:
主キーを設定すると、データベースは自動的にインデックスを作成します。空にすることはできません。一意です。テーブルには主キーを 1 つだけ持つことができます。
単一値インデックス:
インデックスには 1 つの列が含まれており、テーブルには複数の単一値インデックスを含めることができます。
一意のインデックス:
データを繰り返すことはできません
複合インデックス（複合インデックス）
インデックス内の複数の列
結合インデックスの左端のプレフィックスの原則
結合インデックスを使用する場合、左端の列が表示される必要があります。そうでない場合、インデックスは無効になります。
たとえば、テーブルに a、b、c の 3 つの列があるとします。a と b の 2 つの列に対して結合インデックスを作成します。
たとえば、a='' および b='' インデックスが有効になるテーブルから * を選択します。
select * from table where b='' and a='' インデックスが有効になります
select * from table where a='' and c='' インデックスが有効になります
select * from table where b='' and c='' インデックスは有効になりません
%张% のようなファジー クエリ名を使用する; このように記述すると、名前列のインデックスが無効になります。like にファジー クエリを使用することはお勧めできません。
mysql8ではフルテキストインデックスを使用することをお勧めします
全文インデックス
ファジークエリが必要な場合、一般インデックスは無効ですが、フルテキストインデックスを使用できます。
CREATE FULLTEXT INDEX 索引名 ON 表名(字段名) WITH PARSER ngram;
SELECT 结构 FROM 表名 WHERE MATCH(列名) AGAINST(搜索词')
インデックスを見る
SHOW INDEX FROM 表名;
インデックスデータ構造
MySQL Innodb エンジンは、デフォルトでインデックスを保存するデータ構造として B+ 数値を使用します。
ソートすると 1 つのノードに複数のデータを格納でき、横方向に拡張するとデータの高さが低くなります。
非リーフ ノードにはデータは保存されず、インデックスのみが保存されます。さらに多くのインデックスを配置できます。
データレコードはリーフノードに保存されており、インデックスを見つければデータが見つかります。
すべてのリーフ ノード間にはチェーン ポインタがあり、次のような間隔クエリに非常に適しています。 age>20 age<50
クラスター化インデックスと非クラスター化インデックス
クラスター化インデックス:
インデックスが見つかると、データが見つかり、このインデックスはクラスター化インデックスになります。
主キーはデータを直接検索できます
学生番号の値に基づいて学生番号をクエリすると、学生番号を直接ヒットできます。このシナリオでは、学生番号はクラスタ化されています。
非クラスター化インデックス:
インデックスは見つかりましたが、データが見つかりません。主キーに基づいてテーブルを再度クエリする必要があります。
学生番号の値に基づいて学生番号と名前をクエリします。学生番号にはインデックスが付けられていますが、名前も引き続きクエリする必要があります。主キーは学生番号に基づいて見つける必要があり、クエリは次の方法でテーブルに返されます。主キー このシナリオは非クラスター化です。
MyISAM エンジンは、主キー インデックスに対しても非クラスター化設計を使用します。インデックス ファイルとデータ ファイルが同じファイル内にありません。