全体概要
1. データの行は、クラスター化インデックスと呼ばれる innodb のプライマリ インデックス ファイルに直接保存されます。myisam では、セカンダリ インデックスがプライマリ インデックスを指します。とセカンダリ インデックスはどちらも物理行 (ディスクの場所) を指します
はは、私が理解できない言葉を 2 つ言いました。
1つ。よくある説明
これは次のように理解できます:
クラスター化インデックス (innodb): インデックスのリーフ ノードはデータ ノードであり、その下に実際のデータがあります。
非クラスター化インデックス (myisam): リーフ ノードは依然としてインデックス ノードであり、ポインターは対応するデータ ブロックを指します。
写真で説明します:
異なるエンジンの下でタイプが異なることがわかりました。
主な違いは、リーフノードの下にデータブロックがあるかどうかです。
(主キーがない場合は、主キーが作成されます... innodb はクラスター化インデックスによって編成されます)
2.長所と短所:
分割の問題:
ツリー構造であるため、リーフノードが分割される可能性があります
その後、問題が発生します。
非クラスター化インデックス (myisam) の場合、格納される物理行のペアノードの下 アドレスとコンテンツは小さく、メモリにキャッシュされ、すぐに分割されます。
クラスター化インデックス (innodb) の場合、この問題はより深刻です。
ノードの下にデータ ファイルが保存されるため、主キーの場合はノードの分割が遅くなります。 innodb のシェーピングとインクリメントを使用してみてください。シェーピングでは、不規則な主キー データがリーフ ノードに格納されている場合、分割処理は「行データ」で再分割される必要があり、myisam は 1 つのアドレスのみを記録します。アドレスを分割して置き換えるだけです。
例:
たとえば、クラスター化インデックス (innodb) の場合、移動には、クラスター化インデックス (mysiam) の代わりに、ホーム内のすべてのデータを分割して移動するだけで済みます。記録された家の番地を移動しますが、それが指すデータは移動する必要はありません。
3つ。テストデモンストレーション:
innodb エンジンでは、1000 個のデータを 2 つの方法 (定期的と不定期) で挿入できます。
テスト後、主キーの順序が増加する形式での最初の挿入には 37 秒かかりましたが、順序が崩れた場合の 2 回目の挿入には 42 秒かかり、予想される理由はリーフ ノードの必要性です。順不同の挿入により分割される場合、移動には時間がかかります。つまり、時間の違いはノードの分割とページの移動にありますが、順次挿入ではノードの分割が発生することはほとんどありません。
マッピングの結論:
1. 読み取り操作には mysiam エンジンを使用します
2. インデックスとして単調データを選択すると、高速になります
詳細: Mysql インデックスの概要
以下で確認してください。
「%innodb%」のような変数を表示
show status;
フィールド ->innodb_pages_writing (このフィールドに書き込まれたページ数) があることがわかります
ランダムに書き込む場合、書き込みページ数 シーケンシャル書き込みよりも回数が多くなります。これは、分割して移動するため、書き込み回数が多くなり、時間がかかります。これも、5 秒のイベントの差が発生する理由の説明になります。ふたつの間に。
MyISAM:
これは、従来の ISAM タイプに基づくデフォルトのタイプです。 ISAM は、Indexed Sequential Access Method (インデックス付き順次アクセス方式) の略称で、レコードとファイルを格納するための標準的な方法です。他のストレージ エンジンと比較して、MyISAM にはテーブルをチェックおよび修復するためのほとんどのツールが備わっています。 MyISAM テーブルは圧縮でき、全文検索をサポートします。トランザクションセーフではなく、外部キーもサポートしません。ロールバックすると不完全なロールバックが発生し、アトミックではありません。大量に実行すると、 SELECT、MyISAM の方が良い選択です。
InnoDB:
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
