InnoDBテーブルとMyISAMの屈折率差とMySQLでの原則の差（RPM）

InnoDBテーブルとMyISAMのは、多くの人が2つのテーブルのMySQL最も一般的に使用されるタイプを使用している、2つのテーブルのタイプは5.7後も同じではない長所と短所を持っています

1、取引および外部キー

InnoDBはACIDを含む4つのトランザクション分離レベル、ロールバック、クラッシュ修復能力マルチバージョン同時実行性とトランザクションのセキュリティをサポートしTRANSACTIONAL。アプリケーションは、INSERTまたはUPDATE操作の多くを実行する必要がある場合は、のマルチユーザー同時操作のパフォーマンス向上させることができ、InnoDBのを使用する必要がある

のMyISAMは非トランザクションテーブルで管理します。これは、高速ストレージと検索だけでなく、全文検索機能を提供します。アプリケーションは、SELECTクエリの多数を実行する必要がある場合は、MyISAMがより良い選択であります

2、フルテキストインデックス

InnoDBは、我々が使用している場合、それはスフィンクスや他の検索エンジンを使用するのが最善である、フルテキストインデックスをサポートしていません。中国の支援のためのMyISAMは非常に良いではありません

しかし、新しいバージョンでは、InnoDBのをサポートしています

3、ロック

MySQLは、ロック、行レベル、ページレベル、テーブル・レベル、3つのレベルをサポートします。

MyISAMテーブルは、テーブルレベルのロックをサポートし、Oracleは、（選択で読み出した非ロック）を読み取るされていないロックの同じタイプを提供します

MySQLは、SQLステートメントの実装でスキャンする範囲を決定できない場合InnoDBは、InnoDBのテーブルロックはまた、テーブル全体に影響を与えるギャップロックに注意を払うであろう、InnoDBの行ロックテーブルは絶対的ではない、行レベルのロックをサポート

名前は「％のAAA％」のような例如更新テーブルセットNUM = 1

図4に示すように、ストレージ

ディスク上に3つのファイルにMyISAMストレージ。開始するには、テーブルの最初のファイル名の名前は、テーブル定義、データファイル名.MYD、インデックスファイルの拡張子はあるの.frmファイルを格納し、その拡張子のファイル拡張子の種類を指摘.MYI

InnoDBは、ディスクベースのリソースは、InnoDBテーブルスペースのデータファイルとそのログファイルは、InnoDBのテーブルサイズが唯一のオペレーティング・システム・ファイルのサイズに制限されています

注意：MyISAMテーブルは、ファイルの形式で格納され、多くの問題を節約するデータ転送クロスプラットフォームのMyISAMストレージを使用します

5、インデックス

InnoDBは（インデックステーブルを編成）クラスタ化インデックスを使用する、インデックスデータが順次格納され、それはインデックスをキャッシュすることが可能である、データもキャッシュすることができます

非クラスタ化インデックスのMyISAM（ヒープ組織テーブル）を使用し、個別にインデックスファイル、ランダム・アクセス・メモリ、専用キャッシュ・インデックス

6、同時

MyISAMの読み、お互いに書き込むブロック：書かれた時に読み込まブロックすることができるだけでなく、MyISAMテーブルを読んだときに書き込みをブロックすることができますが、それ自体で読み取りが他の読み込みをブロックしません。

トランザクション分離レベルに関連InnoDBの書き込みブロック

7、シーンセレクション

MyISAMテーブル

トランザクションのサポートを必要としません（サポートされていません）
同時比較的低い（ロック機構の問題）
比較的少数のデータ変更（ブロッキング問題）、読み取りほとんど
データの一貫性の要件が非常に高いではありません

インデックス（キャッシュ）を試してみてください
それより大きな優先順位を確保するために重要なアクションの実際のニーズに応じて、読み取りと書き込みの優先順位を調整します
大量に遅延挿入書き込み性能の向上を可能にします
混雑を軽減、データは末尾に書かれている挿入操作の順序を作ってみます
分解大操作、時間をブロッキングを減少するために、単一の操作
キューイングメカニズムを適用することにより行う同時、いくつかの並行性の高いシナリオの数を減らします
比較的静的なデータについては、完全な使用クエリキャッシュが大幅にアクセスの効率を向上させることができ作ります
実際のデータにアクセスする必要がある他の条件で数え、全表スキャンが特に効率的である場合にのみ、MyISAMテーブルのカウント

InnoDBの

トランザクションのサポートが必要です（良好な特性とを総務）
行レベルロックは高い並行処理に適応する優れた能力を持っていますが、クエリがインデックスによって完成されていることを確認する必要があります
より頻繁なデータ更新のシーン
高いデータの一貫性を必要とします
大容量メモリのハードウェアは、あなたはディスクIOを最小限に抑える、InnoDBはより良いキャッシュ、メモリの使用率を改善する能力を使用することができます

可能な限り小さく、主キー、置く過度の負担スペースセカンダリインデックスを避けます
それはテーブル・ロックを使用するため、全表スキャンを避けます
インデックスとキャッシュすべてのデータとして、応答時間を改善
小さな挿入大量のでは、自分の業務をコントロールしようと自動コミット自動送信を使用していません
パラメータ値の合理的なセットをInnodb_flush_log_at_trx_commit、セキュリティを過剰に追求しません
それはデータ移動の多くをもたらすため、プライマリキーの更新を避けます

8、その他の詳細

1）行の数は、COUNT（*）ステートメントは、操作の二種類が同じテーブルであり、条件が含まれている場合に、なお、特にInnoDBストレージテーブルはありません

2）フィールドのAUTO_INCREMENTタイプの場合、InnoDBは、フィールドのインデックスのみが含まれている必要がありますが、あなたがのデータ・ディクショナリのテーブルのAUTO_INCREMENTカラム、InnoDBのテーブルのハンドルを指定した場合、MyISAMテーブルでは、あなたが他のフィールドは、一緒に共同指標を確立することができますこれは、カラムの新しい値を割り当てる際に使用される自動インクリメントカウンタと呼ばれるカウンタを含んでいます。自動インクリメントカウンタは、ディスクが存在するだけではなく、メインメモリに記憶されます

3）FROMテーブル削除すると、InnoDBはテーブルを再確立しますが、行ずつ削除されません

4）MASTER InnoDBの動作からLOAD TABLEは動作しない、溶液は最初InnoDBテーブルのMyISAMテーブルに入れ、次いで、InnoDBテーブルにデータをインポートするが、追加のInnoDB特性（例えば、外部キー）のために使用されますテーブルNA

あなたはSELECTの多くを行う場合は5）、MyISAMテーブルを使用すると、データのINSERTまたはUPDATEの多数を実行する場合、パフォーマンス上の理由から、あなたはInnoDBテーブルを使用する必要があり、より良い選択であります

7.なぜMyISAMテーブルは、クエリ速度のInnoDBよりも高速になります

あなたはMYISAMエンジンよりも多くのものを維持したいときInnoDBがSELECTやって。

1）InnoDBのデータがキャッシュされ、索引付けされる、唯一のMyISAMキャッシュインデックスブロックがスワップアウトされるように低減された中間体が存在します

ブロックにマッピングされる2）のInnoDBアドレス、ファイルは高速INNODBよりOFFSET直接線、MyISAMの記録位置であります

あなたのシーンではないが、彼はまだチェックして維持する必要がある; 3）InnoDBはまた、一貫性のMVCCを維持する必要があります

MVCC（マルチバージョン同時実行制御）マルチバージョン同時実行制御

InnoDBは：各追加の隠された値のための2つの行を追加することによってMVCCを達成するために、これら2つの値のデータのこの行が作成されたときの記録、データのこのラインが満了（または削除）別のレコード。しかし、InnoDBはこれらのイベントが発生し、それが唯一のストレージ・システムのバージョン番号逆に、これらのイベントが発生した実際の時間を保存しません。これは、業務と成長の創出と数です。トランザクションは、独自のシステムのバージョン番号を始めたとき、各トランザクションが記録されます。各クエリは、バージョン番号のデータとトランザクションの各行にバージョン番号をチェックしなければならない同じです。分離レベルがREPEATABLE READであるとき、この戦略は、特定の操作に適用する方法であるとき見てみましょう

SELECT InnoDBは、データの各行は、2つの条件を満たしていることを確認する必要があります

1は、InnoDBが行のバージョンを見つけなければならない、そしてそれは、少なくともトランザクションの古いバージョンなどである（つまり、そのバージョン番号は、トランザクションのバージョン番号よりも大きくありません）。これは、トランザクションの開始前に問題があること、またはラインデータがあるときにトランザクションがデータ・ラインを作成または変更されたときに保証します。

図2は、未定義またはトランザクションのバージョンよりも大きくなければならないデータのこの行のバージョンを削除します。これは、トランザクションが始まる前に何行が削除されていないことを保証します。

8、MySQLのパフォーマンスの議論

ほとんどの人は欠点を批判したのMyISAMは、サポートサービスの欠如であります

InnoDBのディスクパフォーマンスが非常に心配であります

良い表領域のMySQLの不足

二つのタイプの主な違いはINNODB支持トランザクション処理と外部キー、および行レベルロックである。MyISAMテーブルでサポートされていない。したがって、多くの場合、わずかなプロジェクトで使用するのに適していると考えられてMyISAMテーブルに簡単です。

私は、MySQLの出発を使用して、ユーザの視点として、InnoDBはとMyISAMテーブルは、より似ていますが、私の現在の操作と需要を達成するためのデータベースプラットフォームのメンテナンスから：安定性の99.9％は、スケーラビリティと高可用性の利便性がそうである、絶対にMyISAMテーブルそれは私の最初の選択肢です。

次の理由の場合：

私の現在のプロジェクトのすべての最も最初の1は、プラットフォームの読書でホストされていると強いのInnoDBの多くはかなりのパフォーマンスのMyISAMを読むよりも、小規模なプロジェクトをされる書き込み。

2は、MyISAMテーブルインデックスとデータを分離し、そしてインデックスが圧縮され、メモリ使用量が多くを向上させることに対応します。MyISAMテーブルよりもかさばることは小さくないのInnoDBになります圧縮を使用しない、インデックスをロードしてのInnoDBインデックスとデータが密接に結びついているであることができます。

図3は、プラットフォームの観点から、多くの場合、毎月または2つのアプリケーション開発者が誤って適用範囲が通常でテーブルをリードすることができない、書き込まないテーブルを更新していないが発生し、この時間のMyISAM優位性が明らかにただSQLにダンプし、ディレクトリデータベースの下に置くと、圧縮されたファイルコピー日から抽出されたカジュアルな対応表は、メインデータベースに、対応するバイナリログ補数に引き返しました。InnoDBの場合、私はそこに、このような高速にすることができ、Gサイズのデータ量私のプラットフォーム上のデータベース・インスタンスの最小は基本的に数十ので、私は、定期的に輸出xxx.sqlバックアップメカニズムと共にInnoDBを聞かせて言っていないことを恐れています。

4、それとの私の連絡先からアプリケーション・ロジック、SELECT COUNT（*）と最も頻繁によるため、SQL文全体の総運転の60％以上を占めることができるだろうし、これは実際に動作してInnoDBはテーブルをロックしますされます多くの人々は、それは主キーが有効である場合にのみ、非プライマリキーは、テーブル全体をロックすることで、InnoDBは、行レベルのロックだと思います。

彼らは、対応がそのテーブル、MYIファイルをfrm.MYD送るデータベースの対応するバージョンでそれらをできるようにするために5は、部門は、彼らにMyISAMテーブルをいくつかの定期的なデータテーブルを与えるために私を必要とし、多くの場合、アプリケーションがたくさんあり、それは簡単です。ライン上で開始し、他の人に光が、影響を受けたデータ辞書ファイル、相手が使用できないファイルので、あなたは、xxx.sqlのInnoDBをエクスポートする必要があります。

6、それはインデックスに基づいて更新操作のためのものである場合、ライブラリは、追跡することができるからのMyISAMは、InnoDBの、しかし非常に高い同時書き込み小さくてもよいものの比インサートのMyISAMとは、次いで、InnoDBはまだ達しのMyISAM書き込み性能を書く場合それをしない解決するサブライブラリーサブテーブルマルチインスタンス・アーキテクチャなどによっても問題です。

それがある場合は7、その後、エンジンをマージし、MyISAMテーブルを使用して大幅に限り、彼らはいくつかのSELECT COUNT（*）の操作を行うには、テーブルの上にマージとして、それは大規模なプロジェクトのために理想的である、アプリケーション開発部門をスピードアップすることができますのような特定の種類の数百万行の数百（合計約ログ、調査）ビジネステーブル。

もちろん、InnoDBは、このような株式市場のシミュレーションプロジェクトとしてプロジェクト・サービスのために全く使用は、私はアクティブユーザーが20以上万回を使用し、また、非常に簡単InnoDBのではないではない対処ので、私は個人的にも、InnoDBのに似ていますが、データベース・プラットフォーム・アプリケーションの場合出発は、私はまだMyISAMテーブルを好みました。

また、一部の人々は、MyISAMテーブルがあまりにも多くのアンチを書き込むことはできませんあなたが言うかもしれないが、私は私の既存のデータベース・プラットフォームの能力を使用すると言って、アーキテクチャによって相殺することができます、より多くの数百Tよりもマスタースレーブのデータ量を超える10億曲の毎日のPVを動的なページは、（一日あたり9000万クエリを扱う単一のデータベースに結果のmemcachedの始まりは展開しませんでしたので、大きなプロジェクトを含め、）PVの合計数にカウントされないinvokeがデータインタフェースを介して、いくつかの大規模なプロジェクトがあります。そして、周りの0.5-1で私の全体のデータベース・サーバーの負荷平均。

MyISAMのインデックスを実現します

B +ツリーインデックス構造として使用されるのMyISAMエンジンは、リーフ・ノードは、データ・レコードのアドレスデータフィールドに格納されます。図：
MyISAMテーブルの主キーインデックス

ここでは3つのテーブルの合計を提供し、我々はのCol1主キーを想定し、主要指数は、図MyISAMテーブル（主キー）を模式的です。これは、アドレスのみのデータレコードを保存するのMyISAMインデックスファイルを見ることができます。MyISAMテーブルでは、メインインデックスと構造の違い無しセカンダリインデックス（セカンダリキー）が、主インデックスキー要求はユニークであり、補助キーインデックスを繰り返すことができます。当社でcol2上のセカンダリインデックスを構築する場合、このインデックスの構造を以下に示します。
MyISAMのセカンダリインデックス

データフィールドは、データ・レコードを保持し、また、アドレスB +ツリーです。指定されたキーが存在する場合したがって、MyISAMのB +ツリー検索インデックスに従ってインデックス検索アルゴリズムの最初の検索アルゴリズムは、取り出し、そのデータフィールドの値は、その後、アドレスデータフィールドの値は、対応するデータレコードを読み出します。
MyISAMのインデックスモードもそうInnoDBのクラスタ化インデックスを区別するために呼ばれる理由は、「非クラスタ化」と呼ばれています。

InnoDBはインデックスを実現します

InnoDBはまた、B +ツリーインデックス構造が、具体的な実施方法として、異なるMyISAMテーブルと共に使用することがありません。

最初の大きな違いは、InnoDBのデータファイル自体はインデックスファイルであるということです。上記、MyISAMのインデックスファイルとデータファイルから、データレコードに格納されたインデックスファイルのアドレスのみ分離されている既知の。InnoDBのテーブルデータファイル自体では、組織の押し付けB + Treeインデックス構造で、このツリーのリーフノードデータフィールドには、完全なデータの記録を保持しています。このインデックスは、キーデータテーブルの主キーなので、InnoDBのテーブルデータファイル自体は、メインインデックスです。
InnoDBの主な指標

図は概略図InnoDBの主な指標（データファイル）である、あなたはリーフノードは完全なデータ・レコードが含まれて見ることができます。このインデックスは、クラスタ化インデックスと呼ばれています。InnoDBのデータファイル自体Yaoan主キーの集約ので、InnoDBはテーブルに主キー（MyISAMテーブルができない）を持っている必要がありますが必要ですので、主キーは一意のデータレコードを識別するようがないがある場合は、明示的に指定しない場合は、MySQLのシステムは自動的に、列を選択しますこの列は、MySQLは自動的にこのフィールドには、長整数型として、長さは6バイトで、主キーInnoDBテーブルとして隠しフィールドを生成します。

第2の相違点は、MyISAMテーブルインデックスInnoDBの二次インデックスフィールドデータを格納するレコードを主キー値の代わりに、アドレスに対応するということです。換言すれば、全てのセカンダリインデックスのInnoDBは、プライマリキーのデータフィールドとして挙げられます。例えば、以下に定義はCOL3にセカンダリインデックスを示しています。
InnoDBのセカンダリインデックス

ここでは、比較基準としてASCII英文字インチこの実装クラスタ化インデックスは、検索高効率の主キーを押して行いますが、セカンダリインデックスの検索インデックスは二回取得する必要があります：最初の補助主キーインデックスが取得され、取得、および、取得したレコードを取得するために、主キーにプライマリ・インデックスを使用します。

概要

データベースの開発では、インデックスのインデックスの実装および最適化の適切な使用のために理解して別々のストレージエンジンは非常に有用です。例えば、達成するためにインデックスの後のInnoDBを知って、それはすべてのセカンダリインデックスはメインインデックスへの参照であるため、主キーとして長いフィールドの使用を推奨しない理由は簡単で、長いメインインデックスがセカンダリインデックスが大きくなりすぎるようになります。別の例として、非単調なフィールドのInnoDBデータファイル自体はB +ツリーであるため、InnoDB内の主キーは、お勧めではないように、非単調な主キーは+ツリー特性Bを維持するために新たな記録データファイルの挿入をもたらします頻繁分割は、非常に非効率的に調整し、プライマリキーは良い選択であるとして、自動インクリメントフィールドを使用します。