MyISAM は、MySQL バージョン 3.23 でのデフォルトのテーブル型です。この型は ISAM コードに基づいており、多数の便利な拡張機能を備えています。
インデックスは .MYI(MYIndex)拡張子の付いたファイルに、データは .MYD(MYData)拡張子の付いたファイルにそれぞれ格納されます。MyISAM テーブルは、myisamchk ユーティリティで検査および修復することができます。See 項4.5.6.7. 「myisamchk を使用したクラッシュのリカバリ」。 また、MyISAM テーブルを myisampack で圧縮することで、使用する領域を大幅に削減できます。 See 項4.8.4. 「myisampack(MySQL 圧縮読み取り専用テーブルジェネレータ)」。
MyISAM の新機能は次のとおりです。
MyISAM ファイルには、テーブルが正しく閉じられたかどうかを示すフラグがある。mysqld を起動する際に --myisam-recover を指定すると、MyISAM テーブルを開く際にそのテーブルが正しく閉じられたかどうかが自動的に検査され、必要であれば修復される。
データファイル内に空きブロックがないテーブルに対し、他のスレッドがそのテーブルから読み取りを行うのと同時に新しいレコードを INSERT できる(同時挿入)。空きブロックは、大量のデータを含んだ可変長レコードに含まれるデータの長さが短くなるような更新をした場合、またはレコードを削除した場合に発生する。すべての空きブロックを使い切ると、それ以後の挿入は再び同時挿入になる。
大きなファイルをサポートするファイルシステム/オペレーティングシステムで、大きなファイル(63 ビット)がサポートされる。
すべてのデータが下位バイトから順に格納される。これによって、データがマシンと OS に依存しなくなる。バイナリ移植性を実現するための唯一の要件は、2 の補数で表現された符号付き整数(すべてのマシンで過去 20 年間使われていた形式)および IEEE 浮動小数点形式(同じく主流のマシンでの主要な形式)をマシンで使用することである。マシンにおいてバイナリ互換性をサポートしていない可能性がある領域は、埋め込みシステムのみ(特殊なプロセッサを使用している場合があるため)。
データを下位バイトから先に格納しても、速度上大きな問題はない。テーブルロー内のバイトは通常整列されておらず、未整列のバイトを順番に読み取る操作は、逆順に読み取る操作に比べてそれほど処理能力を必要としないからである。また、実際のカラムの値を読み取るコードも他のコードに比べて速度が重視されない。
すべての数値キーを上位バイトから先に格納して、インデックスの圧縮効率を高めている。
1 つの AUTO_INCREMENT カラムを内部処理している。MyISAM では、このカラムが INSERT/UPDATE で自動更新される。AUTO_INCREMENT の値は、myisamchk でリセットできる。これによって AUTO_INCREMENT カラムの処理が速くなる(最低でも 10%)。また、以前の ISAM のように古い番号が再使用されない。マルチパートキーの最後の項目に AUTO_INCREMENT が定義されている場合は、以前の動作が引き続き有効となることに注意する。
キーツリーは、ソートされた順序で挿入されると(AUTO_INCREMENT カラムを使用しているときなど)、分割されて上位ノードにキーが 1 つだけ含まれるようになる。これによって、キーツリーでの領域利用率が向上する。
BLOB カラムと TEXT カラムにインデックスを作成できる。
インデックスが作成されたカラムで NULL 値が許可される。この場合、1 キー当たり 0 ? 1 バイトが使用される。
最大キー長のデフォルト値は 500 バイト(再コンパイルで変更可能)。長さが 250 バイトを超えるキーの場合は、デフォルトの 1,024 バイトより大きなキーブロックサイズが使用される。
テーブル当たりの最大キー数のデフォルト値は 32。この数値は、myisamchk を再コンパイルしなくても 64 まで拡大できる。
myisamchk を --update-state 付きで実行すると、テーブルが検査済みとしてマークされる。 myisamchk --fast は、このマークがないテーブルのみを検査する。
myisamchk -a は、キーの各部分(ISAM のようにキー全体だけではなく)に関する統計情報を格納する。
更新/挿入と削除が混在している場合に、可変長レコードがフラグメント化されることが少なくなった。これは、隣接する削除済みブロックの結合、および次のブロックが削除されている場合のブロックの拡張が自動的に行われるようになったためである。
myisampack で、BLOB および VARCHAR カラムをパックできる。
データファイルとインデックスファイルを別々のディレクトリに配置して速度を高めることができる(CREATE TABLE の DATA/INDEX DIRECTORY="path" オプションを使用)。 See 項6.5.3. 「CREATE TABLE 構文」。
MyISAM は、MySQL で近い将来使用可能となる次の機能もサポートしています。
真の VARCHAR 型のサポート。VARCHAR カラムは、長さを示す 2 バイトの値で始まる。
VARCHAR を使用するテーブルには、固定長と可変長のレコードを収容できる。
VARCHAR および CHAR は 64K まで可能。すべてのキーセグメントには、それぞれ独自の言語定義がある。これによって、MySQL ではカラムごとに言語定義を変えられる。
計算されたハッシュインデックスを UNIQUE インデックスとして使用できる。これによって、テーブル内のカラムの任意の組み合わせを UNIQUE インデックスにすることができる(ただし、計算された UNIQUE インデックスでの検索は不可能)。
通常、インデックスファイルは ISAM よりも MyISAM の方がはるかに小さいので注意してください。つまり、MyISAM は一般に ISAM よりも少ないシステムリソースを使用しますが、圧縮されたインデックスへデータを挿入する際により多くの CPU 時間を必要とします。
次に示す mysqld のオプションを使用して、MyISAM テーブルの動作を変更することができます。 See 項4.6.8.4. 「SHOW VARIABLES」。
| オプション | 説明 |
--myisam-recover=# | クラッシュしたテーブルの自動リカバリ。 |
-O myisam_sort_buffer_size=# | テーブルをリカバリする際に使用されるバッファ。 |
--delay-key-write=ALL | すべての MyISAM テーブルに対して、書き込み間でキーバッファをフラッシュしない。 |
-O myisam_max_extra_sort_file_size=# | 速度は遅くても安全なキーキャッシュインデックス作成方法をどの時点で使用するかを MySQL が判断できるようにする。注意: このパラメータを指定する単位として、4.0.3 より前はメガバイト、このバージョンからはバイトを使用する。 |
-O myisam_max_sort_file_size=# | テンポラリファイルがこの値を超えた場合に、作成されたインデックスに対して高速なソートインデックス方法を使用しない。注意: このパラメータを指定する単位として、4.0.3 より前はメガバイト、このバージョンからはバイトを使用する。 |
-O bulk_insert_buffer_size=# | バルク挿入の最適化で使用されるツリーキャッシュのサイズ。注意: これはスレッド当たりの制限値。 |
--myisam-recover=# を指定して mysqld を起動すると、自動リカバリがアクティブ化されます。See 項4.1.1. 「mysqld コマンドラインオプション」。 テーブルが開く際に検査されます。検査の内容は、テーブルにクラッシュのマークが付いているかどうか、またはテーブルのオープンカウント変数が 0 ではなく、かつ --skip-external-locking で実行しているかどうかです。上記のどちらかが当てはまる場合は、次の処理が行われます。
テーブルにエラーがないかどうかが検査される。
エラーが見つかった場合は、テーブルの高速修復(ソートは行うがデータファイルは再構築しない)を試みる。
データファイルにエラーがあるために(重複キーエラーなど)修復が失敗した場合は、もう一度修復を試みるが、今度はデータファイルを再構築する。
この修復が失敗した場合は、以前の修復方法(ソートせずに 1 レコードずつ書き込む方法)で再度修復を試みる。この方法で、どのようなエラーでもわずかなディスク容量で修復できるはずである。
myisam-recover のオプションとして FORCE を指定しなかった場合に、直前に完了したステートメントからすべてのレコードをリカバリできないときは、自動修復が中止され、エラーファイルに次のエラーメッセージが書き込まれます。
Error: Couldn't repair table: test.g00pages
FORCE オプションを指定していた場合は、上記のメッセージの代わりに次の警告がエラーファイルに書き込まれます。
Warning: Found 344 of 354 rows when repairing ./test/g00pages
注意: BACKUP オプションを指定して自動リカバリを実行する場合は、tablename-datetime.BAK のような名前のファイルをデータベースディレクトリからバックアップメディアに自動的に移動する cron スクリプトを用意する必要があることに注意してください。















