MySQL の InnoDB ストレージ エンジンと MyISAM ストレージ エンジンの違い

MySQLこのデータベースを他のデータベースと区別する非常に重要な機能は、データベースではなくテーブルに基づくプラグイン テーブル ストレージ エンジンです。各ストレージ エンジンには独自の特性があるため、テーブルごとに最適なストレージ エンジンを選択できます。

DBA として、ストレージ エンジンについて深く理解する必要があります。今日は、最も一般的な 2 つのストレージ エンジン、InnoDB と MyISAM を紹介します。

InnoDB ストレージ エンジン

InnoDBストレージ エンジンはトランザクションとその主要な設計をサポートします。目標は、OLTP (オンライン トランザクション処理) 用のアプリケーションです。機能には、行ロック設計、外部キーのサポート、非ロック読み取りのサポートが含まれます。バージョン 5.5.8 から、InnoDB が MySQL のデフォルトのストレージ エンジンになりました。

InnoDBストレージ エンジンはクラスター化インデックスを使用してデータを保存するため、各テーブルは主キーの順序で保存されます。主キーが指定されていない場合は、InnoDB は、各行の 6 バイト ROWID を主キーとして自動的に生成します。

#MyISAMストレージ エンジン

MyISAMストレージ エンジンはトランザクションとテーブル ロックをサポートしていません主に OLAP (オンライン分析処理) アプリケーション向けの全文インデックス作成をサポートしており、データ ウェアハウスなど頻繁にクエリを行うシナリオに適しています。 5.5.8 バージョンより前は、MyISAM が MySQL のデフォルトのストレージ エンジンでした。このエンジンは、大量のデータのクエリと分析のニーズを表します。パフォーマンスを重視しているため、クエリの実行速度は InnoDB よりも高速です。

#InnoDB と MyISAM

Transaction

# の違い##データベース操作のアトミック性のためには、トランザクションが必要です。送金機能など、一連の操作がすべて成功するか失敗するかを確認します。通常、トランザクションを形成するには、begin

と

commit の間に複数の SQL ステートメントを配置します。 InnoDB

はサポートされていますが、

MyISAM はサポートされていません。 主キー

InnoDB

のクラスター化インデックスのため、主キーが指定されていない場合、主キーは自動的に生成されます。

MyISAM 主キーのないテーブルの存在をサポートします。
外部キー

複雑なロジックの依存関係を解決するには、外部キーが必要です。たとえば、大学入学試験の成績のエントリは特定の学生に属している必要があるため、大学入学試験の成績データベースへの入学チケット番号を含む外部キーが必要です。

InnoDB

はサポートされていますが、

MyISAM はサポートされていません。 インデックス

クエリ、並べ替え検索、一致検索の速度を最適化するには、インデックスが必要です。たとえば、全員の名前は a-z

の最初の文字から順に保存されており、

zhangsan または 44 の位置を検索すると、すぐに名前を見つけることができます。希望の場所を見つけます。 InnoDB

はクラスター化インデックスです。データは主キーのクラスター化インデックスにバインドされています。主キーを使用したインデックス作成は非常に効率的です。他の列の補助インデックスを介して検索する場合は、最初にクラスター化インデックスを見つけてから、すべてのデータをクエリする必要があり、これには 2 つのクエリが必要です。

MyISAM

は非クラスター化インデックスであり、データ ファイルは分離されており、インデックスにはデータのポインターが保存されます。

InnoDB 1.2.x

バージョン、

MySQL5.6 バージョン以降、両方ともフルテキスト インデックス作成をサポートします。

auto_increment

自動インクリメント自動インクリメント フィールドの場合、InnoDB

では列がインデックスである必要があり、これはインデックスの最初の列である必要があります。そうでない場合は、エラーが報告されます:

mysql> create table test(
    -> a int auto_increment,
    -> b int,
    -> key(b,a)
    -> ) engine=InnoDB;
ERROR 1075 (42000): Incorrect table definition; there can be only one auto column and it must be defined as a key

(b,a) の順序を

(a,b)# に置き換えるだけです。 ##。 および MyISAM は、このフィールドを他のフィールドと任意の順序で組み合わせて、結合インデックスを形成できます。

テーブル行数

非常に一般的な要件は、テーブル内にデータがいくつあるかを確認することです。この時点では、select count が必要です。 (*) table_name より。

InnoDBテーブルの行数は保存されず、テーブル全体のスキャンが必要です。

MyISAM

変数に保存し、値を直接読み取るほうが高速です。そのとき、where でクエリすると、この 2 つは同じでした。 ストレージ

データベースのファイルはディスクに保存され、アプリケーションが必要なときにメモリに読み込まれる必要があります。通常、データ ファイルとインデックス ファイルが含まれます。

InnoDB

は次のように分割されます:

.frm

テーブル構造ファイル

• .ibdata1 共有テーブルスペース
• .ibd排他テーブルスペース
• .redoログファイル
• ##MyISAM3 つのファイルに分割されています:

.frmストレージ テーブル定義

• .MYDストレージ テーブル データ
#.MYI
• ストレージ テーブル インデックス
• 実行速度

  操作が SELECT などの多数のクエリ操作である場合、MyISAM を使用するとパフォーマンスが向上します。
  ほとんどの操作が削除と変更である場合は、InnoDB を使用します。

  InnoDB と MyISAM のインデックスは両方とも B ツリー インデックスです。データの主キーはインデックスを通じてクエリできます。 B Tree では、MySQL InnoDB インデックスの原則とアルゴリズムを表示できます。 2 つのパフォーマンスの違いは主に、データの主キーをクエリした後の処理方法の違いにあります。

  InnoDB は、インデックス ファイルとデータ ファイルをキャッシュします。通常、16KB は、ディスク InnoDB と対話するための最小単位 (データ ページ サイズ) として使用されます。 インデックス データをクエリした後、実際に取得するのは主キーの ID です。メモリ内のデータ ページ内の行のすべてのデータを検索する必要があります。ただし、データがホット データはロードされていません。まだ実行する必要があります。 データ ページの検索と置換には、複数の I/O 操作とメモリ内のデータ検索が含まれる場合があり、その結果、時間がかかります。

  AndMyISAMストレージ エンジンはインデックス ファイルのみをキャッシュし、データ ファイルはキャッシュしません。データ ファイルのキャッシュはオペレーティング システムのキャッシュを直接使用するという非常にユニークな点です。現時点では、同じスペースでより多くのインデックスをロードできるため、キャッシュ スペースが限られている場合、MyISAM のインデックス データ ページの置換時間は短くなります。先ほどの情報によれば、MyISAM のファイルは MYI と MYD に分割されており、主キー ID## から # が見つかると、 ##MYI #、実際には、MYD データ ファイルの offset オフセットが取得され、データの検索は InnoDB のアドレス指定よりもはるかに高速です。マッピング。 ただし、

  MyISAM

  はテーブル ロックであり、InnoDB は行ロックをサポートしているため、多数の書き込み操作が関係する場合、InnoDB の同時実行パフォーマンスが低下します。 MyISAM よりもはるかに優れています。同時に、InnoDB は MVVC マルチバージョン コントロールも使用して、同時読み取りおよび書き込みのパフォーマンスを向上させます。

  deleteデータの削除

  delete from table

  を呼び出すと、MyISAM は直接table 、 InnoDB は行ごとに削除されますが、 truncate table で置き換えることができます。参考：mysqlでテーブルデータをクリアする2つの方法と違い。 #Lock

  MyISAM

  テーブル ロックのみをサポートし、操作ごとにテーブル全体がロックされます。

  InnoDB 行ロックをサポートし、操作ごとに最小数のデータ行をロックします。
  行ロックと比較して、テーブル ロックは消費するリソースが少なく、デッドロックが発生しませんが、同時に同時実行パフォーマンスは低くなります。行ロックはより多くのリソースを消費し、速度が遅く、デッドロックを引き起こす可能性がありますが、ロックの粒度が小さくデータが小さいため、同時実行パフォーマンスは良好です。 InnoDB

  のステートメントがスキャン対象の範囲を決定できない場合、テーブル全体もロックされます。

  行ロックのデッドロックが発生すると、各トランザクションの影響を受ける行数が計算され、行数が少ないトランザクションがロールバックされます。

  データ復旧

  MyISAM

  クラッシュ後に迅速かつ安全に復旧する方法はありません。

  InnoDB には完全な回復メカニズムがあります。 データ キャッシュ

  MyISAM

  インデックス データのみをキャッシュし、インデックスを通じてデータをクエリします。

  InnoDB インデックス データをキャッシュするだけでなく、データ情報もキャッシュし、データはページ単位でキャッシュ プールに読み込まれ、LRU (latest Rare Use) アルゴリズムに従って更新されます。

  ストレージ エンジンの選択方法

  テーブルを作成するステートメントはすべて同じですが、最後の type## のみです。 # ストレージ エンジンを指定します。

  MyISAM

  1. 合計 count

  2 という大量のクエリ。頻繁に発生するクエリ##3. トランザクション操作なし

  #InnoDB

  #1. 高可用性が必要、またはトランザクションが必要2. テーブルの頻繁な更新 推奨学習:

  MySQL チュートリアル

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