MySQLメモリストレージエンジンに関する知識

メモリストレージエンジンに関する知識ポイント

メモリ ストレージ エンジンは日常業務ではほとんど使用されませんが、一部の MySQL 構文ではメモリ エンジンのメモリ テーブルが使用されます。メモリ エンジンには次の特徴があります。

1. メモリ テーブルを作成する構文は、create table … engine=memory です。

2. このテーブルのデータはメモリに保存され、システムを再起動するとクリアされますが、テーブル構造はそのまま残ります。

2. メモリ ストレージ エンジンのデータとインデックスは分離されています。メモリ ストレージ エンジンのテーブルには主キーも設定できます。主キー ID には各データの場所が格納されます。主キー ID はハッシュ インデックスであり、インデックス上のキーは連続していません。

データとインデックスが別々に格納されるこのデータ編成形式は「ヒープ編成テーブル」と呼ばれ、Innodb ストレージ エンジンの「インデックス編成テーブル」とは異なります。

Innodbとメモリストレージエンジンの違い

1. メモリ ストレージ エンジンのデータ格納順序は挿入順序と同じですが、InnoDB ストレージ エンジンのデータ格納順序はクラスター化インデックスに従って順序付けられます。以下にいくつか例を挙げます。

mysql> テーブル t1(id int 主キー、c int) を作成します。engine=Memory;
クエリは正常、影響を受けた行は 0 行 (0.00 秒)

mysql> t1 に値 (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(0,0); を挿入します。
クエリは正常、10 行が影響を受けました (0.00 秒)
記録: 10 重複: 0 警告: 0

mysql> t1 から * を選択します。
+----+------+
| id | c |
+----+------+
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
| 6 | 6 |
| 7 | 7 |
| 8 | 8 |
| 9 | 9 |
| 0 | 0 |
+----+------+
セット内の行数は 10 です (0.00 秒)


mysql> テーブル t2(id int 主キー、c int) を作成します。engine=innodb;
クエリは正常、影響を受けた行は 0 行 (0.01 秒)

mysql> t2 に値 (1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(9,9),(0,0); を挿入します。
クエリは正常、10 行が影響を受けました (0.00 秒)
記録: 10 重複: 0 警告: 0


mysql> t2 から * を選択します。
+----+------+
| id | c |
+----+------+
| 0 | 0 |
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 4 |
| 5 | 5 |
| 6 | 6 |
| 7 | 7 |
| 8 | 8 |
| 9 | 9 |
+----+------+
セット内の行数は 10 です (0.00 秒)

メモリ ストレージ エンジンの結果では、レコード (0,0) が最後にあり、挿入順序と一致しているのに対し、InnoDB ストレージ エンジンの結果では、レコードの順序に従って配置されていることがわかります。

2. データ ファイルに穴がある場合、InnoDB ストレージ エンジンは指定された場所にデータを挿入する必要がありますが、メモリ ストレージ エンジンはギャップが見つかる限りデータを挿入できます。

3. データの場所が変更されると、メモリ ストレージ エンジンはすべてのインデックスを変更する必要がありますが、InnoDB ストレージ エンジンは主キー インデックスのみを変更する必要があります。

4. InnoDB ストレージ エンジンではクエリ時に「テーブル リターン」がありますが、メモリ ストレージ エンジンではテーブル リターンは必要ありません。

5. InnoDB ストレージ エンジンは varchar をサポートしていますが、メモリ ストレージ エンジンはサポートしていません。すべての varchar は char として扱われます。また、メモリ ストレージ エンジンは blob フィールドとテキスト フィールドをサポートしていません。

6. メモリ ストレージ エンジンは範囲クエリをサポートできません。インデックスタイプがハッシュインデックスであるため

実稼働環境では、通常、次の 2 つの理由によりメモリ テーブルを使用することは推奨されません。

1. メモリ テーブルは行ロックをサポートしておらず、テーブル ロックのみをサポートしています。テーブルが更新されると、読み取り操作を含むテーブル上の他の操作はブロックされます。つまり、このようなテーブルの同時実行パフォーマンスは低くなります。

2. データの永続性が低い。データベースがクラッシュすると、メモリ テーブル内のデータが失われます。テーブルからの削除ステートメントを binlog に書き込むのを忘れますが、テーブル構造はまだ存在します。デュアル M 環境では、スレーブ データベースがクラッシュした場合、この削除ステートメントによってマスター データベースの一時テーブル データが汚染される可能性があり、これは比較的危険な操作です。

上記はMySQL Memoryストレージエンジンに関する詳細な内容です。MySQL Memoryストレージエンジンの詳細については、123WORDPRESS.COMの他の関連記事をご覧ください。