InnoDBとMyISAMの主な違いは何ですか?
私が目にする最初の大きな違いは、InnoDBが行レベルのロックを実装しているのに対し、MyISAMはテーブルレベルのロックしか実行できないことです。 InnoDBの方がクラッシュリカバリが向上します。ただし、MyISAMと同様に、v5.6まではFULLTEXT
検索インデックスはありません。 InnoDBはトランザクション、外部キー、および関係の制約も実装していますが、MyISAMは実装していません。
リストは少し先に進むことができます。それでも、どちらにも有利な点と不利な点があります。それらのそれぞれは、いくつかのシナリオで他よりも適しています。
要約すると(TL; DR):
FULLTEXT
検索インデックスがあり、InnoDBはMySQL 5.6(2013年2月)まではありませんでした。まだ言及されていないもう1つの大きな違いは、各ストレージエンジンのキャッシュがどのように行われるかです。
使用される主なメカニズムはキーキャッシュです。 .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バッファープールのサイズを設定するには、次のクエリを実行します。
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つしかない場合のサイズを以下に示します。
service mysql stop
rm /var/log/mysql/ib_logfile[01]
service mysql start
(ib_logfile0およびib_logfile1が再作成されます)両方のクエリの最後にインラインクエリがあります(SELECT 2 PowerOf1024)
B
(SELECT 0 PowerOf1024)
はバイト単位の設定を示します(SELECT 1 PowerOf1024)
はキロバイト単位の設定を示します(SELECT 2 PowerOf1024)
はメガバイト単位の設定を示します(SELECT 3 PowerOf1024)
設定をギガバイトで示します常識に代わるものはありません。メモリが限られている、ストレージエンジンが混在している、またはそれらの組み合わせがある場合は、さまざまなシナリオに合わせて調整する必要があります。
可能なシナリオは無限です!!!
何を割り当てても、DB接続とオペレーティングシステム用に十分なRAMを残してください)。
InnoDBが提供するもの:
InnoDBでは、TEXTとBLOBを除く行内のすべてのデータは、最大で8,000バイトを占有できます。 MySQL 5.6(2013年2月)まで、フルテキストインデックスはInnoDBでは使用できません。 InnoDBでは、COUNT(*)
s(WHERE
、_GROUP BY
_、またはJOIN
が使用されない場合)は、行数が内部に格納されないため、MyISAMよりも実行速度が遅くなります。 InnoDBは、データとインデックスの両方を1つのファイルに格納します。 InnoDBはバッファプールを使用して、データとインデックスの両方をキャッシュします。
MyISAMが提供するもの:
COUNT(*)
s(WHERE
、_GROUP BY
_、またはJOIN
が使用されていない場合)MyISAMにはテーブルレベルのロックがありますが、行レベルのロックはありません。トランザクションはありません。自動クラッシュリカバリはありませんが、修復テーブルの機能は提供されます。外部キーの制約はありません。 MyISAMテーブルは、InnoDBテーブルと比較すると、通常、ディスク上のサイズがコンパクトです。 MyISAMテーブルは、必要に応じてmyisampackで圧縮することにより、サイズをさらに大幅に削減できますが、読み取り専用になります。 MyISAMは、インデックスを1つのファイルに保存し、データを別のファイルに保存します。 MyISAMはキーバッファーを使用してインデックスをキャッシュし、データキャッシュの管理はオペレーティングシステムに任せます。
全体として、私はほとんどの目的でInnoDBを、MyISAMを特別な用途でのみお勧めします。新しいMySQLバージョンでは、InnoDBがデフォルトのエンジンになりました。
ゲームには少し遅れますが、非常に包括的です 数か月前に書いた投稿 、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未満です。つまり、FULLTEXTインデックスはInnoDBテーブルではサポートされていません。
ただし、これはMyISAMを使用する正当な理由ではありません。 MySQLの最新バージョンをサポートするホスティングプロバイダーに変更することをお勧めします。 FULLTEXTインデックスを使用するMyISAMテーブルはInnoDBテーブルに変換できないことに注意してください。
結論として、InnoDBはデフォルトのストレージエンジンとして選択する必要があります。特定のニーズに対応する場合は、MyISAMまたはその他のデータタイプを選択します。
もう1つ:ファイルシステムのスナップショットを取得するだけでInnoDBテーブルをバックアップできます。 MyISAMのバックアップにはmysqldumpの使用が必要であり、一貫性があるとは限りません(たとえば、親テーブルと子テーブルに挿入した場合、バックアップでは子テーブルの行しか見つからない可能性があります)。
基本的に、データの別のコピーがあり、それをMySQLにのみキャッシュしている場合、 PHP Webサイトからアクセスする標準的な手段を許可する場合、MyISAMは問題ありません(つまり、クエリと同時アクセスのためのフラットCSVファイルまたはログファイルよりも優れています)。データベースがデータの実際の「マスターコピー」。ユーザーからの実際のデータを使用してINSERT
およびUPDATE
を実行している場合、MyISAMがあらゆる規模でInnoDB以外のものを使用するのは愚かです信頼性が低く、管理が難しいため、半分の時間でmyisamchk
を実行し、パフォーマンスの向上を無効にします...
(私の個人的な経験:MyISAMの2テラバイトDB)。
私の経験では、最も大きな違いは、各エンジンがロックを処理する方法です。 InnoDBは行ロックを使用し、MyISAMはテーブルロックを使用します。経験則として、私は重いテーブルの書き込みにはInnoDBを使用し、重いテーブルの読み取りにはMyISAMを使用します。
その他の重要な違いは次のとおりです。
MyISAMはMySQLの「デフォルト」のテーブル選択と見なす傾向があるため、InnoDBのほとんどのユーザーの違いを指摘します
MySQL 5.6の変更を含む
INNODBストレージエンジン:
したがって、すでに5.6にアップグレードされている場合はMyISAM
Engineを使用しても意味がありません。そうでない場合は、MySQL 5.6へのアップグレードを待つ必要はありません。
[〜#〜] myisam [〜#〜]
MYISAMは、テーブルレベルのロック、フルテキスト検索を提供します。 MYISAMは、すべてのストレージエンジンをオフにして最も柔軟なAUTO_INCREMENTED列を処理します。 MYISAMはトランザクションをサポートしていません。
[〜#〜] innodb [〜#〜]
INNODBはトランザクションセーフストレージエンジンです。 INNODBには、コミット、ロールバック、およびクラッシュ回復機能があります。 INNODBは外部キーの参照整合性をサポートします。
MyISAMはMySQLのストレージエンジンです。 MySQL 5.5以前は、MySQLのデフォルトのストレージエンジンでした。これは、古いISAMストレージエンジンに基づいています。MyISAMは、読み取り操作が多く、書き込みが少ないか、まったくない環境向けに最適化されています。MyISAMが高速読み取りを可能にする理由は、インデックス:各エントリはデータファイル内のレコードを指し、ポインタはファイルの先頭からオフセットされます。これにより、特にフォーマットがFIXEDの場合、レコードをすばやく読み取ることができます。したがって、行の長さは一定です。A MyISAMが好まれる典型的な領域はデータウェアハウスです。これは非常に大きなテーブルに対するクエリを含み、そのようなテーブルの更新はデータベースが使用されていないときに行われます(通常は夜間)。新しい行があるため、挿入も簡単ですはデータファイルの最後に追加されます。ただし、削除と更新の操作にはさらに問題があります。削除を行うと空のスペースが残るか、行のオフセットが変更されます。更新の場合も、行の長さが短くなると同じことが起こります。更新によって行が長くなると、行は断片化されます。行を入力し、空のスペースを要求します。OPTIMIZE TABLE
コマンドを実行する必要があります。この単純なメカニズムのため、通常MyISAMインデックス統計は非常に正確です。 MyISAMの他の主な欠点は、トランザクションサポートと外部キーがないことです。
InnoDBはMySQLのストレージエンジンです。 MySQL 5.5以降ではデフォルトで使用します。これは、外部キーのサポート(宣言的参照整合性)とともに、標準のACID準拠のトランザクション機能を提供します。 SQLとXAの両方のトランザクション、テーブルスペース、FULLTEXT
インデックス、OpenGIS標準に準拠した空間操作を実装します。これは、一部のOEMバージョンを除き、MySQL ABによって配布されるほとんどのバイナリに標準で含まれています。ソフトウェアはオラクル社によって二重ライセンスされています。 GNU General Public Licenseの下で配布されていますが、独自のソフトウェアにInnoDBを組み合わせたいと考えている当事者にもライセンスを付与できます。
MariaDBにはAriaと呼ばれるストレージエンジンがあり、これは「MyISAMのクラッシュセーフな代替手段」として説明されています。 MariaDBとPercona Serverは、デフォルトでXtraDBと呼ばれるInnoDBのフォークを使用します。 XtraDBはPerconaによって保守されています。 Oracle InnoDBの変更は定期的にXtraDBにインポートされ、いくつかのバグ修正と追加機能が追加されています。