MySQLストレージエンジンMyISAMとInnoDBが詳細に話し合う

I.概要

MySQLデータベースは、MyISAM、InnoDB、MERGE、MEMORY（HEAP）、BDB（BerkeleyDB）、EXAMPLE、FEDERATED、ARCHIVE、CSV、BLACKHOLEなどのさまざまなストレージエンジンをサポートしています。

次のshow engines手順で、システムにインストールされているMySQLのエンジンタイプのサポートを確認できます。
ここに画像の説明を挿入

show variables like '%storage_engine%'手順を使用して、MySQLがデフォルトで使用するストレージエンジンを表示することもできます。次の図から、システム上のMySQLのデフォルトのストレージエンジンがInnoDBであることがわかります。
ここに画像の説明を挿入

私のMySQLバージョンは5.7.32です。MyISAMはMySQLに
ここに画像の説明を挿入
付属のストレージエンジンです。InnoDBはサードパーティ企業によって開発され、プラグインの形でMySQLに統合されています。
バージョン5.5より前は、MyISAMはMySQLのデフォルトのデータベースエンジンでした。それ以降のバージョンのMySQLは、デフォルトでより多くのInnoDBを使用していました。

この記事では、主に一般的に使用されるMyISAMとInnoDBについて説明します。

2つ目は、MyISAMとInnoDBが詳細に話し合う

1.比較する

1.ストレージ構造
1）MyISAM
各MyISAMは、ディスク上に3つのファイルとして保存されます。最初のファイルの名前はテーブルの名前で始まり、拡張子はファイルタイプを示します。
.frm：テーブル構造ファイル
。MYD：データファイル
。MYI：インデックスファイル

インデックスファイルは、レコードが配置されているデータファイルの場所を保存します。インデックスファイルを読み取って位置情報を取得した後、データファイルを読み取ることでデータをすばやく取得します。
ここに画像の説明を挿入
2）InnoDBに
は2つのファイルしかありません：
.frm：テーブル構造ファイル
。ibd：データ、インデックスファイル

InnoDBは、クラスター化インデックスを使用してBツリーインデックスを実装します。クラスター化インデックスは、データ行と隣接する主キーをファイルにコンパクトに格納することで実装されます。
InnoDBテーブルのサイズは、オペレーティングシステムファイルのサイズ（通常は2GB）によってのみ制限されます。
ここに画像の説明を挿入
InnoDBは、テーブルスペース（テーブルスペース）を使用してデータを管理し、テーブルデータとインデックスを格納します。mysql5.6.6より前は、共有表スペースが使用され、それ以降のバージョンでは単一表スペースが使用されていました。

共有表スペース：ibdata1およびibdata2はDataフォルダーに保管され、すべての表が共有されます。
単一の表スペース：グローバル変数を介して開くことができます。開いた後、各表には、それに対応する.ibdがあります。

# When innodb_file_per_table is enabled (the default in 5.6.6 and higher), InnoDB stores the data and indexes for each newly created table
# in a separate .ibd file, rather than in the system tablespace.
innodb_file_per_table=1

show variables like '%innodb_file_per_table%'mysqlが命令を介して別個の表スペースを開くかどうかを確認できます。
ここに画像の説明を挿入
共有表スペースと単一表スペースの長所と短所：
1）単一表スペース
長所：-
各表には独自の独立表スペースがあります。
-各表のデータと索引は、独自の表スペースに保管されます。
-1つのテーブルを異なるデータベースに移動できます。
-スペースを再利用できます（テーブル操作のドロップ/切り捨てテーブルスペースを自動的に再利用することはできません）。
-独立したテーブルスペースを使用するテーブルの場合、どのように削除しても、テーブルスペースの断片化はパフォーマンスにそれほど深刻な影響を与えることはなく、それに対処する機会があります。
短所：
-単一テーブルの増加は、共有スペース方式よりも大きくなります。

2）共通の表スペース
利点：
-表スペースを複数のファイルに分割して各ディスクに保管できます（表スペースのファイルサイズは、テーブルを異なるファイルに分散できるなど、テーブルサイズによって制限されません）。
-サイズ制限はファイルサイズ制限ではなく、独自の制限です。Innodbの公式ドキュメントからわかるように、テーブルスペースの最大制限は64TBです。

短所：-すべての
データとインデックスが1つのファイルに保存されます。非常に大きなファイルがあります。大きなファイルは複数の小さなファイルに分割できますが、複数のテーブルとインデックスがテーブルスペースに保存されます。多数の削除後操作は表に対して実行されます。特に統計分析の場合、表スペースには多数のギャップがあります。ログ・システムは、共有表スペースなどのアプリケーションにはあまり適していません。

2.トランザクション
1）MyISAM
はトランザクションをサポートしていません。パフォーマンスを重視し、実行はInnoDBタイプよりも高速です。

2）InnoDB
はトランザクションをサポートします。外部キーなどの高度なデータベース機能を提供します。
InnoDBのAUTOCOMMITはデフォルトでオンになっています。つまり、各SQLステートメントはデフォルトでトランザクションにカプセル化されて自動的に送信されますが、これは効率に影響します。トランザクションをマージし、beginとcommitの間に複数のSQLステートメントを表示してコンポジションを形成できます。データベースの複数の送信によって引き起こされるオーバーヘッドを削減し、パフォーマンスを向上させるトランザクション。

3. CURD操作
1）MyISAM

多数の選択を実行する場合は、MyISAMが最適です。

2）InnoDB

INSERTまたはUPDATEを大量に実行する場合は、パフォーマンスの観点からInnoDBを使用する必要があります。
実行するとdelete from table、InnoDBはテーブルを再作成しませんが、行ごとに削除します。
load table from masterこの操作はInnoDBでは機能しません。解決策：InnoDBをMyISAMテーブルに変更し、データをインポートしてから、InnoDBに変更します。ただし、追加のInnoDB機能（外部キー）を使用するテーブルには適用されません。

4、AUTO_INCREMENT
1）MyISAM

MyISAMは、INSERTおよびUPDATE操作のためにこの列を自動的に更新し、AUTO_INCREMENT列を高速化します。シーケンスの先頭の値が削除された後は、再利用できません。（AUTO_INCREMENT列が複数列インデックスの最後の列として定義されている場合、シーケンスの先頭から削除された値を再利用できます）
AUTO_INCREMENT値は、ALTERTABLEまたはmyisamchを使用してリセットできます。
タイプAUTO_INCREMENTのフィールドの場合、他のフィールドとのジョイントインデックスを確立できます。

2）InnoDB

テーブルにAUTO_INCREMENT列を指定すると、データディクショナリのInnoDBテーブルハンドルには、列に新しい値を割り当てるために使用される自動インクリメントカウンターと呼ばれるカウンターが含まれます。
自動インクリメントカウンタはメインメモリにのみ保存され、ディスクには保存されません。

5、テーブル行
1）MyISAM
固有の行数クエリ内のMyISAMストレージテーブルは、テーブル内の行数をクエリするselect count(*) from tableときに、保存する行数を読み取るだけです。
ただし、count（*）ステートメントにwhere条件が含まれている場合は、テーブル全体をスキャンして行数を取得する必要があります。

2）InnoDB
InnoDBは、テーブル内の特定の行数を保存しません。テーブルからselect count（*）を実行すると、InnoDBはテーブル全体をスキャンして、行数を計算します。

6.
テーブルレベルのロックをロックする：-テーブルを挿入すると、テーブルレベルのロックがテーブル全体をロックします。
-オーバーヘッドが低く、ロックが高速で、デッドロックがなく、ロックの粒度が大きく（テーブル全体）、同時実行性が低く、ロック競合の可能性が高くなります。
行レベルのロック：-行レベルのロックを使用して、1つのデータの複数の属性を変更します。
-高いオーバーヘッド、遅いロック、デッドロック、最小のロック粒度（1行のデータ）、高い同時実行性、および低いロック競合確率。
ページレベルのロック：-データは1ページとしてディスクに保存されます。1ページは4Kです。比較的大きなテーブル（数千万など）の場合、この時点でテーブルデータの一部をロックすると、1回の操作のみが許可されます。 1ページに。
-オーバーヘッド、ロック速度、ロックの粒度、および同時実行性はすべて、テーブルレベルのロックと行レベルのロックの間にあり、デッドロックが発生します。

1）MyISAM
はテーブルロックを提供します。

2）InnoDB
は、行ロックとテーブルロックを提供します。

行ロックは、インデックスアイテムをロックすることで実装されます。これは、次の状況では失敗し、テーブル全体をロックします。

などのインデックス条件でデータを取得しませんupdate table set a=1 where user like '%lee%'。
DELETE FROM mytableそのような削除ステートメント。

7.テーブルの主キー
1）MyISAM
では、インデックスと主キーのないテーブルが存在できます。インデックスは、行が格納されるアドレスです。

2）InnoDB
は、主キーインデックスのインデックス値（主キーの値）を格納し、各列のデータも格納します。主キーが設定されていない場合、主キーとして外部キーを使用しようとします。外部キーがない場合、非表示のROWIDが主キーとして自動的に生成されます。InnoDBの主キー範囲は大きく、MyISAMの最大2倍です。

8.フルテキストインデックス
1）MyISAM
は（FULLTEXTタイプ）フルテキストインデックスをサポートします。

2）InnoDB
は（FULLTEXTタイプの）フルテキストインデックス作成をサポートしていませんが、sphinxプラグインを使用してフルテキストインデックス作成をサポートでき、効果が向上します。

Q：InnoDBがフルテキストインデックスをサポートしないのはなぜですか？
InnoDBデータはすでにノード上にあります。フルテキストのインデックスを作成する場合は、データベースをコピーするのと同じです。

Q：ブログシステムの記事にはどのストレージエンジンを使用する必要がありますか？
ブログシステムの記事はMyISAMに保存することをお勧めします。InnoDBのリーフノードは記事の保存に使用されるため、リーフノードが大きすぎて記事の保存には適していません。ブログシステムのフルテキストインデックスは、クエリの要約とMD5値です。

Q：データを見つけるのに速いのはどれですか？
テーブルの場合、MyISAMはテーブル全体のインデックスツリーをメモリに追加し、それをディスク上で見つけることができます。InnoDBは、データを直接取得できるため、データの一部をメモリに追加します。
（データが少ない）データを見つけるために、クエリするデータが多い場合、MyISAMはInnoDBよりも高速であり、InnoDBはMyISAMよりも高速です。これは、MyISAMがディスクを読み取るたびにデータを読み取るためです。一般的に使用されるデータを保存できます。データの一部はメモリに保存されます。

2.使用シナリオ

1）MyISAM

読み取り操作が主な業務であり、UPDATEは比較的小さいため、MyISAMの使用に適しています。
並行性は高くありません。
テーブルデータの量は少ないです。
ハードウェアリソースは限られています。

2）InnoDB

読み取りと書き込みの量は少なく、大きなフィールドは頻繁に更新されます。InnoDBを選択してください。
テーブルのデータ量が1,000万を超え、同時実行性が高い。
安全性と信頼性の要件は高いです。