InnoDBとMyISAMの主な違いは何ですか？

私が見る最初の大きな違いは、InnoDBが行レベルのロックを実装しているのに対し、MyISAMはテーブルレベルのロックしか実行できないことです。InnoDBのクラッシュリカバリが優れています。ただし、FULLTEXTMyISAMと同様に、v5.6まで検索インデックスがありません。InnoDBはトランザクション、外部キー、および関係制約も実装しますが、MyISAMは実装しません。

リストはもう少し先に進むことができます。しかし、どちらもお互いに有利な点と不利な点で独自の利点があります。シナリオによっては、それぞれが他のシナリオよりも適しています。

要約すると（TL; DR）：

• InnoDBには行レベルのロックがあり、MyISAMは完全なテーブルレベルのロックのみを実行できます。
• InnoDBのクラッシュリカバリが改善されました。
• MyISAMにはFULLTEXT検索インデックスがありますが、InnoDBにはMySQL 5.6までありませんでした（2013年2月）。
• InnoDBはトランザクション、外部キー、および関係制約を実装しますが、MyISAMは実装しません。

まだ言及されていないもう1つの大きな違いは、各ストレージエンジンのキャッシング方法です。

MYISAM

使用される主なメカニズムはキーキャッシュです。.MYIファイルのインデックスページのみをキャッシュします。キーキャッシュのサイズを設定するには、次のクエリを実行します。

SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.4999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1))
recommended_key_buffer_size FROM
(SELECT LEAST(POWER(2,32),KBS1) KBS
FROM (SELECT SUM(index_length) KBS1
FROM information_schema.tables
WHERE engine='MyISAM' AND
table_schema NOT IN ('information_schema','mysql')) AA ) A,
(SELECT 2 PowerOf1024) B;

これにより、現在のデータセットからMyISAMキーキャッシュの推奨設定（key_buffer_size）が得られます（クエリは推奨を4G（4096M）に制限します。32ビットOSの場合、4GBが制限です。64ビット、8GBの場合

InnoDB

使用される主なメカニズムは、InnoDBバッファープールです。アクセスされたInnoDBテーブルのデータとインデックスページをキャッシュします。InnoDBバッファープールのサイズを設定するには、次のクエリを実行します。

SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.49999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1)) recommended_innodb_buffer_pool_size
FROM (SELECT SUM(data_length+index_length) KBS FROM information_schema.tables
WHERE engine='InnoDB') A,
(SELECT 2 PowerOf1024) B;

これにより、現在のデータセットに応じて、InnoDBバッファープールのサイズの推奨設定（innodb_buffer_pool_size）が得られます。

InnoDBログファイル（ib_logfile0およびib_logfile1）のサイズを変更することを忘れないでください。MySQLソースコードは、すべてのInnoDBログファイルの合計サイズの上限を<4G（4096M）にする必要があります。単純にするために、ログファイルが2つだけの場合、次のようにサイズを変更できます。

• 手順1）innodb_log_file_size = NNNを/etc/my.cnfに追加します（NNNはinnodb_buffer_pool_sizeの25％または2047Mのうち小さい方）
• ステップ2） service mysql stop
• ステップ3） rm /var/log/mysql/ib_logfile[01]
• ステップ4）service mysql start（ib_logfile0およびib_logfile1が再作成されます）

警告

両方のクエリの最後には、インラインクエリ (SELECT 2 PowerOf1024)B

• (SELECT 0 PowerOf1024) 設定をバイト単位で与えます
• (SELECT 1 PowerOf1024) 設定をキロバイト単位で与えます
• (SELECT 2 PowerOf1024) 設定をメガバイト単位で与えます
• (SELECT 3 PowerOf1024) 設定をギガバイト単位で与えます
• 0未満または3を超えるパワーは受け入れられません。

エピローグ

常識に代わるものはありません。メモリが限られている、ストレージエンジンが混在している、またはそれらの組み合わせがある場合は、さまざまなシナリオに合わせて調整する必要があります。

• 2GBのRAMと16GBのInnoDBがある場合、innodb_buffer_poolとして512Mを割り当てます。
• 2GBのRAMと4GBのMyISAMインデックスがある場合、512Mをkey_buffer_sizeとして割り当てます。
• 2GBのRAMと4GBのMyISAMインデックスと16GBのInnoDBがある場合、512Mをkey_buffer_sizeとして、512Mをinnodb_buffer_pool_sizeとして割り当てます。

可能なシナリオは無限です!!!

割り当てたものは何でも、DB接続とオペレーティングシステムに十分なRAMを残してください。

InnoDBが提供するもの：

• ACIDトランザクション
• 行レベルのロック
• 外部キー制約
• 自動クラッシュリカバリ
• テーブル圧縮（読み取り/書き込み）
• 空間データ型（空間インデックスなし）

InnoDBでは、TEXTおよびBLOBを除く行のすべてのデータは最大で8,000バイトを占有できます。InnoDBでは、MySQL 5.6（2013年2月）までフルテキストインデックスは使用できません。InnoDB内でCOUNT(*)S（場合WHERE、GROUP BYまたはJOIN行カウントが内部に格納されていないため、使用されていない）は、MyISAMテーブルよりも遅く実行します。InnoDBは、データとインデックスの両方を1つのファイルに保存します。InnoDBは、バッファープールを使用してデータとインデックスの両方をキャッシュします。

MyISAMが提供するもの：

• 速いCOUNT(*)S（ときWHERE、GROUP BYまたはJOIN使用されていません）
• 全文索引付け（更新：MySQL 5.6のInnoDBでサポート）
• より小さなディスクフットプリント
• 非常に高いテーブル圧縮（読み取り専用）
• 空間データ型とインデックス（Rツリー）（更新：MySQL 5.7からのInnoDBでサポート）

MyISAMにはテーブルレベルのロックがありますが、行レベルのロックはありません。トランザクションはありません。自動クラッシュリカバリはありませんが、修復テーブル機能を提供します。外部キーの制約はありません。MyISAMテーブルは、InnoDBテーブルと比較すると、ディスク上のサイズが一般的にコンパクトです。MyISAMテーブルは、必要に応じてmyisampackで圧縮することでサイズをさらに大幅に削減できますが、読み取り専用になります。MyISAMは、あるファイルにインデックスを保存し、別のファイルにデータを保存します。MyISAMはインデックスのキャッシュにキーバッファーを使用し、データキャッシュ管理をオペレーティングシステムに任せます。

全体として、ほとんどの目的にはInnoDBを、特殊な用途にのみMyISAMをお勧めします。InnoDBは現在、新しいMySQLバージョンのデフォルトエンジンです。

もう1つ：ファイルシステムのスナップショットを取るだけでInnoDBテーブルをバックアップできます。MyISAMのバックアップにはmysqldumpの使用が必要であり、一貫性が保証されていません（たとえば、親テーブルと子テーブルに挿入する場合、バックアップで子テーブルの行のみが見つかる場合があります）。

基本的に、データの別のコピーがあり、MySQLにのみキャッシュしている場合（たとえば、PHP Webサイトから標準的なアクセス方法を許可する場合）、MyISAMは問題ありません（つまり、フラットCSVファイルまたはクエリ用のログファイルよりも優れています）同時アクセス）。データベースがデータの実際の「マスターコピー」である場合、ユーザーからの実際のデータを実行INSERTおよびUPDATE使用している場合、MyISAMは信頼性が低く、管理が難しい規模でInnoDB以外のものを使用するのは愚かなことです。 「やっているでしょうmyisamchk任意のパフォーマンス向上を否定、半分の時間を...

（私の個人的な経験：MyISAMの2テラバイトのDB）。

ゲームに少し遅れました...しかし、ここに私が数ヶ月前に書いた非常に包括的な記事があり、 MYISAMとInnoDBの主な違いを詳述しています。カップパ（おそらくビスケット）を手に取り、楽しんでください。

MyISAMとInnoDBの主な違いは、参照整合性とトランザクションです。ロック、ロールバック、全文検索など、その他の違いもあります。

参照整合性

参照整合性により、テーブル間の関係の一貫性が維持されます。より具体的には、これは、テーブル（リストなど）が別のテーブル（製品など）を指す外部キー（製品IDなど）を持っている場合、ポイント先のテーブルに対して更新または削除が発生すると、これらの変更がリンクにカスケードされることを意味しますテーブル。この例では、製品の名前が変更されると、リンクテーブルの外部キーも更新されます。製品が「製品」テーブルから削除された場合、削除されたエントリを指すリストも削除されます。さらに、新しいリストには、有効な既存のエントリを指す外部キーが必要です。

InnoDBはリレーショナルDBMS（RDBMS）であるため、参照整合性がありますが、MyISAMはありません。

トランザクションと原子性

テーブル内のデータは、SELECT、INSERT、UPDATE、DELETEなどのデータ操作言語（DML）ステートメントを使用して管理されます。トランザクションは、2つ以上のDMLステートメントを1つの作業単位にグループ化するため、単位全体が適用されるか、まったく適用されません。

MyISAMはトランザクションをサポートしませんが、InnoDBはサポートします。

MyISAMテーブルの使用中に操作が中断されると、操作はすぐに中止され、操作が完了しなかった場合でも、影響を受ける行（または各行内のデータ）が影響を受けたままになります。

InnoDBテーブルの使用中に操作が中断された場合、原子性を持つトランザクションを使用しているため、コミットが行われないため、完了に至らなかったトランザクションは有効になりません。

テーブルロックと行ロック

MyISAMテーブルに対してクエリを実行すると、クエリを実行しているテーブル全体がロックされます。これは、後続のクエリが現在のクエリが終了した後にのみ実行されることを意味します。大きなテーブルを読み込んでいる場合、および/または頻繁な読み取りおよび書き込み操作がある場合、これはクエリの膨大なバックログを意味する可能性があります。

InnoDBテーブルに対してクエリを実行すると、関係する行のみがロックされ、テーブルの残りの部分はCRUD操作で使用可能なままになります。つまり、同じ行を使用しない限り、クエリは同じテーブルで同時に実行できます。

InnoDBのこの機能は、同時実行性と呼ばれます。並行性と同様に、選択範囲のテーブルに適用される大きな欠点があります。カーネルスレッドの切り替えにオーバーヘッドがあり、サーバーが停止しないようにカーネルスレッドに制限を設定する必要があります。 。

トランザクションとロールバック

MyISAMで操作を実行すると、変更が設定されます。InnoDBでは、これらの変更をロールバックできます。トランザクションの制御に使用される最も一般的なコマンドは、COMMIT、ROLLBACK、およびSAVEPOINTです。1. COMMIT-複数のDML操作を記述できますが、変更はCOMMITが行われた場合にのみ保存されます2. ROLLBACK-まだコミットされていない操作を破棄できます3. SAVEPOINT-リストのポイントを設定しますROLLBACK操作がロールバックできる操作

信頼性

MyISAMはデータの整合性を提供しません-ハードウェア障害、正常でないシャットダウン、キャンセルされた操作により、データが破損する可能性があります。これには、インデックスとテーブルの完全な修復または再構築が必要です。

一方、InnoDBは、トランザクションログ、二重書き込みバッファー、および自動チェックサムと検証を使用して破損を防ぎます。InnoDBは、変更を行う前に、トランザクションの前のデータをibdata1というシステムテーブルスペースファイルに記録します。クラッシュが発生した場合、InnoDBはこれらのログの再生を通じて自動回復します。

全文索引付け

InnoDBは、MySQLバージョン5.6.4まではFULLTEXTインデックス作成をサポートしていません。この投稿の執筆時点では、多くの共有ホスティングプロバイダーのMySQLバージョンはまだ5.6.4未満です。つまり、InnoDBテーブルではFULLTEXTインデックスはサポートされていません。

ただし、これはMyISAMを使用する正当な理由ではありません。MySQLの最新バージョンをサポートするホスティングプロバイダーに変更することをお勧めします。FULLTEXTインデックスを使用するMyISAMテーブルをInnoDBテーブルに変換できないということではありません。

結論

結論として、InnoDBはデフォルトのストレージエンジンとして選択する必要があります。特定のニーズに応える場合は、MyISAMまたはその他のデータタイプを選択します。

私の経験では、最も重要な違いは、各エンジンがロックを処理する方法です。InnoDBは行ロックを使用し、MyISAMはテーブルロックを使用します。経験則として、重いテーブルの書き込みにはInnoDBを、重いテーブルの読み取りにはMyISAMを使用します。

その他の重要な違いは次のとおりです。

1. InnoDBはトランザクションと外部キーをサポートします。MyISAMはサポートしていません。
2. MyISAMは全文索引付けを使用します。
3. MyISAMは、データの整合性を強制するという貧弱な仕事をしています。

私はMyISAMをMySQLの「デフォルト」テーブル選択と見なす傾向があるため、InnoDBのほとんどのユーザーの違いを指摘します。

• 行レベルロック
• 外部キーの実施
• 取引サポート
• 使用頻度の高いシステムのパフォーマンスヒット

MYISAM

MYISAMは、テーブルレベルのロック、全文検索を提供します。MYISAMには、すべてのストレージエンジンを処理する最も柔軟なAUTO_INCREMENTED列があります。MYISAMはトランザクションをサポートしていません。

INNODB

INNODBはトランザクションセーフなストレージエンジンです。INNODBには、コミット、ロールバック、クラッシュ回復機能があります。INNODBは外部キー参照整合性をサポートします。

MySQL 5.6の変更を含む

INNODBストレージエンジン：

• ACID（原子性、一貫性、分離、耐久性）に完全に準拠しています。マルチバージョン管理は、トランザクションを相互に分離するために使用されます。
• InnoDBは、MySQLサーバーまたはサーバーが実行されているホストのクラッシュ後に自動回復を提供します。
• InnoDBは、カスケードされた削除と更新を含む外部キーと参照整合性をサポートします。
• MySQL 5.6は、デフォルトのストレージエンジンとして完全に統合されたInnoDBのプラットフォーム上に構築されます
• Persistent Optimizer Stats：InnoDBインデックス統計の精度を向上させ、MySQLの再起動全体で一貫性を提供します。
• InnoDBテーブルキャッシュの整理：膨大な数のテーブルがあるシステムのメモリ負荷を軽減するために、InnoDBは開かれたテーブルに関連付けられたメモリを解放するようになりました。LRUアルゴリズムは、アクセスされずに最長になったテーブルを選択します。
• フルテキスト検索のサポート：特別な種類のインデックスであるFULLTEXTインデックスは、InnoDBがテキストベースの列とそれに含まれる単語を含むクエリとDML操作を処理するのに役立ちます。これらのインデックスは、InnoDBテーブル全体として物理的に表されます。
• InnoDBは、MyISAMよりもフルテキスト検索ではるかに高速であるようです

したがって、MyISAMすでに5.6にアップグレードされている場合はEngine を使用しても意味がありません。そうでない場合は、MySQL 5.6へのアップグレードを待たないでください。

MySQL 5.6を使用したInnoDB VS MyISAMのパフォーマンス

MyISAM

MyISAMは、MySQL用のストレージエンジンです。MySQL 5.5より前は、MySQLのデフォルトのストレージエンジンでした。これは、古いISAMストレージエンジンに基づいています。MyISAMは、読み取り操作が多く、書き込みが少ない、またはまったくない環境向けに最適化されています。MyISAMが高速読み取りを許可する理由は、インデックスの構造です。各エントリはデータファイル内のレコードを指し、ポインターはファイルの先頭からオフセットされます。この方法により、特にフォーマットが修正されている場合、レコードをすばやく読み取ることができます。したがって、行の長さは一定です。MyISAMを好む典型的な領域はデータウェアハウスです。これは、非常に大きなテーブルでのクエリを含み、そのようなテーブルの更新はデータベースが使用されていないとき（通常は夜間）に行われるためです。データファイルの末尾に新しい行が追加されるため、挿入も簡単です。しかしながら、削除と更新の操作にはさらに問題があります。削除では空のスペースを残す必要があります。そうしないと、行のオフセットが変更されます。行の長さが短くなるため、更新についても同じことが言えます。更新により行が長くなると、行は断片化されます。行を最適化し、空のスペースを要求するには、OPTIMIZE TABLEコマンドを実行する必要があります。この単純なメカニズムのため、通常MyISAMインデックス統計は非常に正確です。MyISAMのその他の主な欠点は、トランザクションサポートと外部キーがないことです。

InnoDB

InnoDBはMySQLのストレージエンジンです。MySQL 5.5以降ではデフォルトで使用されます。外部キーのサポート（宣言参照整合性）とともに、標準のACID準拠のトランザクション機能を提供します。FULLTEXTOpenGIS標準に従って、SQLおよびXAトランザクション、テーブルスペース、インデックス、および空間操作の両方を実装します。一部のOEMバージョンを除き、MySQL ABによって配布されるほとんどのバイナリに標準として含まれています。このソフトウェアは、オラクル社によってデュアルライセンスされています。GNU General Public Licenseの下で配布されますが、InnoDBをプロプライエタリソフトウェアに結合することを希望する関係者にもライセンス供与できます。

フォーク

MariaDBにはAriaというストレージエンジンがあり、これは「MyISAMのクラッシュセーフな代替手段」と言われています。MariaDBとPercona Serverは、デフォルトでXtraDBと呼ばれるInnoDBのフォークを使用します。XtraDBはPerconaによって管理されています。Oracle InnoDBの変更はXtraDBに定期的にインポートされ、いくつかのバグ修正と追加機能が追加されています。