mysql ストレージ エンジン: myIsam と innodb の違い

MySQL には複数のストレージ エンジンがあり、MyISAM と InnoDB の 2 つは一般的に使用されます。これら 2 つのエンジンに関する基本概念をいくつか紹介します (詳細な紹介ではありません)。

MyISAM は MySQL のデフォルトのストレージ エンジンです。従来の ISAM タイプに基づいており、全文検索をサポートしていますが、トランザクションセーフではなく、外部キーをサポートしていません。各 MyISAM テーブルは 3 つのファイルに格納されます: frm ファイルはテーブル定義を格納し、データ ファイルは MYD (MYData)、インデックス ファイルは MYI (MYIndex) です。

InnoDB は、ロールバック、クラッシュ リカバリ、マルチバージョン同時実行制御、ACID トランザクション、行レベルのロック (InnoDB テーブルの行ロックは絶対的なものではありません。MySQL が SQL を実行している場合) をサポートするトランザクション エンジンです。ステートメント スキャンするスコープを決定できない場合、InnoDB テーブルはテーブル全体 (like 操作中の SQL ステートメントなど) もロックし、Oracle タイプと一致するロックフリーの読み取りメソッドを提供します。 InnoDB はテーブルとインデックスをテーブルスペースに保存します。テーブルスペースには複数のファイルを含めることができます。

主な違い

MyISAM は非トランザクション的に安全ですが、InnoDB はトランザクション的に安全です。

MyISAM ロックの粒度はテーブル レベルですが、InnoDB は行レベルのロックをサポートします。

MyISAM はフルテキスト タイプのインデックスをサポートしますが、InnoDB はフルテキスト インデックスをサポートしません。

MyISAM は比較的シンプルなので、効率の点では InnoDB よりも優れており、小規模なアプリケーションでは MyISAM の使用を検討できます。

MyISAM テーブルはファイルの形式で保存されます。クロスプラットフォームのデータ転送で MyISAM ストレージを使用すると、多くの手間が省けます。

InnoDB テーブルは MyISAM テーブルよりも安全です。データが失われないようにしながら、非トランザクション テーブルをトランザクション テーブルに切り替えることができます (alter table tablename type=innodb)。

アプリケーション シナリオ

MyISAM は非トランザクション テーブルを管理します。高速な保存と取得、および全文検索機能を提供します。アプリケーションで大量の SELECT クエリを実行する必要がある場合は、MyISAM の方が良い選択です。

InnoDB はトランザクション処理アプリケーションに使用され、ACID トランザクションのサポートを含む多数の機能を備えています。アプリケーションで大量の INSERT または UPDATE 操作を実行する必要がある場合は、マルチユーザーの同時操作のパフォーマンスを向上できる InnoDB を使用する必要があります。

Mysql ストレージ エンジンとインデックス

データベースにはインデックスが必要です。インデックスがないと、取得プロセスは順次検索になります。時間計算量は O(n) です。ほとんど耐えられないほどです。キーがツリーのノードに格納されている限り、B ツリーを使用して 1 つのキーのみで構成されるテーブルにどのようにインデックスを付けることができるかを想像するのは非常に簡単です。データベース レコードに複数のフィールドが含まれる場合、B ツリーは主キーのみを格納できるため、非主キー フィールドが取得されると、主キー インデックスはその機能を失い、再び順次検索になります。この時点で、取得する 2 番目の列に 2 番目のインデックス セットを確立する必要があります。インデックスは独立した B ツリーによって編成されます。複数の B ツリーが同じテーブル データ セットにアクセスする問題を解決するには 2 つの一般的な方法があります。1 つはクラスター化インデックス (クラスター化インデックス) と呼ばれ、もう 1 つは非クラスター化インデックス (セカンダリ インデックス) と呼ばれます。これら 2 つの名前は両方ともインデックスと呼ばれますが、これらは別個のインデックス タイプではなく、データの保存方法です。クラスター化インデックス ストレージの場合、行データと主キー B ツリーは一緒に保存され、副キー B ツリーは副キーと主キーのみを保存します。主キー B ツリーと非主キー B ツリーは、ほぼ 2 種類のツリーです。非クラスター化インデックス ストレージの場合、主キー B ツリーは、主キーの代わりにリーフ ノード内の実際のデータ行へのポインターを格納します。

InnoDB はクラスター化インデックスを使用して主キーを B ツリーに編成し、行データはリーフ ノードに保存されます。「where id = 14」という条件を使用して主キーを検索すると、 B ツリー検索アルゴリズムは、対応するリーフ ノードを見つけて行データを取得します。 Name 列で条件検索を実行する場合は、2 つの手順が必要です。最初の手順では、補助インデックス B ツリーで Name を取得し、そのリーフ ノードに到達して、対応する主キーを取得します。 2 番目のステップでは、主キーを使用して主インデックス B ツリーに対して別の B ツリー検索操作を実行し、最終的にリーフ ノードに到達してデータ行全体を取得します。

MyISM は非クラスター化インデックスを使用します。非クラスター化インデックスの 2 つの B ツリーは、見た目は変わりません。ノードの構造はまったく同じですが、格納されているコンテンツは異なります。プライマリのノードキー インデックス B ツリーには主キーが格納され、副キー インデックス B ツリーには副キーが格納されます。テーブル データは別の場所に格納されます。2 つの B ツリーのリーフ ノードは、アドレスを使用して実際のテーブル データを指します。テーブル データの場合、2 つのキーに違いはありません。インデックス ツリーは独立しているため、副キーによる検索では主キーのインデックス ツリーにアクセスする必要はありません。

これら 2 つのインデックスの違いをより明確に説明するために、以下に示すようにテーブルに 4 行のデータが格納されていると仮定します。このうち、Id はプライマリ インデックスとして機能し、Name はセカンダリ インデックスとして機能します。この図は、クラスター化インデックスと非クラスター化インデックスの違いを明確に示しています。

クラスター化インデックスに焦点を当てます。クラスター化インデックスの効率は、補助インデックスを使用するたびに非クラスター化インデックスの効率よりも明らかに低いようです。インデックスを取得するには 2 回実行する必要があります。B ツリー検索、これは不要ではないでしょうか。クラスター化インデックスの利点は何ですか?

1 行データと葉ノードが一緒に格納されているので、主キーと行データも一緒にメモリにロードされ、葉ノードが見つかったらすぐに行データを返すことができます。主キー ID を指定すると、データを迅速に更新できます。

2 補助インデックスは、アドレス値をポインタとして使用するのではなく、主キーを「ポインタ」として使用するため、行の移動やデータ ページの分割が発生した場合の補助インデックスのメンテナンス作業が軽減されるという利点があります。 . 主キーの値はポインターとして使用されます。これにより、補助インデックスがより多くのスペースを占有するようになります。利点は、行を移動するときに InnoDB が補助インデックスの「ポインター」を更新する必要がないことです。つまり、行の位置 (実装では 16K ページに配置されます。これについては後で説明します) は、データベース内のデータの変更 (以前の B ツリー ノード分割とページ分割) に応じて変更されます。主キー B ツリーのノードがどのように変化しても、補助インデックス ツリーは影響を受けないことが保証されています。

したがって、数百万のデータやより大きなデータの場合、mysql innoDB のインデックス パフォーマンスはさらに優れています。

以上がmysql ストレージ エンジン: myIsam と innodb の違いの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。