InnoDB の安全性、一貫性、セルフチェック機能が気に入っています。
しかし、MyISAM の速度と軽量さが必要です。
クラッシュや不良データなどによる MyISAM の破損を防ぐにはどうすればよいですか? チェック (CHECK TABLE または myisamchk のいずれか) を通過するのに永遠に時間がかかります。
私はトランザクションのセキュリティを求めているわけではありません。それが InnoDB の目的です。しかし、数時間 (または数日!) 後ではなく、すぐに再起動できるデータベースが必要です。
更新:テーブルにデータをより速くロードする方法を尋ねているのではありません。私はすでにそれに対して頭を悩ませており、LOAD DATA に MyISAM テーブルを使用する方がはるかに高速であると判断しました。私が今求めているのは、MyISAM テーブルを使用するリスクを軽減することです。つまり、損傷の可能性を減らし、回復速度を上げます。
MyISAMの想定される速度の利点は、実際にはすぐになくなる可能性があります。行レベルのロックがないという事実は、小さな更新によって大量のデータがロックされ、クエリがブロックされる可能性があることを意味します。そのため、MyISAMの速度の利点については懐疑的です。いくつかの更新を開始すると、1秒あたりのクエリ数が減少します。
「InnoDBでバックアップされたアプリケーションをどのように高速化できるか」と尋ねた方がよいと思います。そして、その答えは、おそらくオブジェクトレベルで、軽量キャッシュにデータをキャッシュすることを扱います。ACIDにはコストがかかり、たとえばWebアプリケーションの場合、実際には必要ありません。
UPDATEがまれな場合（そうでない場合、MyISAMは適切な選択ではありません）、MySQLクエリキャッシュを使用することもできます。
memcached（http://www.danga.com/memcached/）は、オブジェクトキャッシングで非常に人気のあるオプションです。アプリケーションに応じて、他のオプションもあります（HTTPキャッシュなど）。
MyISAM のパフォーマンス上の利点は、場合によっては実際にはごくわずかです。独自のアプリケーション MyISAM と InnoDB のベンチマークを行う必要があります。InnoDB トランザクション エンジンを排他的に使用すると、他の利点も得られます。
私のテストでは、通常、InnoDB は MyISAM よりも約 150% 多いディスク容量を使用します。これは、ブロック構造とインデックス圧縮の欠如によるものです。
余裕がある場合は、代わりに InnoDB を使用してください。
実際の質問に答える限り、テーブルを複数の MyISAM テーブルに分割すると、クラッシュ時に必要な修復の量がはるかに少なくなります。データが大きい場合は、他の理由でとにかくこれが良い考えかもしれません。
innodb のコメントには同意しますが、MyISAM の問題に対する解決策を提供します。
破損を防ぎ速度を上げる良い方法は、MERGE テーブルを使用することです。
2 つ以上の MyISAM ファイルを使用できます。1 つは通常、あまり使用されない古いデータのバックアップ用で、もう 1 つは新しいデータ用です。次に、ハードディスクに 2 つの FRM (MyISAM テーブル ファイル) があり、1 つが保護されます。通常、古い MyISAM テーブルを圧縮すると、それらは読み取り専用になるため、破損することはありません。
この手法は通常、大きな MyISAM テーブルを高速化するために使用されますが、ここでも適用できます。
ご質問のお役に立てば幸いです。MyISAM のクラッシュ防止にはあまり役立たないことはわかっていますが、かなりの保護を提供します。
通常の実践では、破損することはありません。破損している場合は、不良メモリ、不良ハード ドライブ、不良ドライブ コントローラ、または mysql バグなどを調べる必要があります。
これらすべてを回避したい場合は、レプリケーション スレーブを設定できます。マスターが停止したら、スレーブでのレプリケーションを停止し、それを新しいマスターにします。古いマスターからデータを消去し、スレーブとして設定します。ユーザーのダウンタイムは、マスターが停止したことを検出してスレーブを起動するのにかかる時間に制限されます。
これには、ゼロ ダウンタイムのバックアップを実現するための優れた方法であるという追加の利点があります。スレーブ プロセスをシャットダウンし、スレーブをバックアップします。
あなたのコメント：
いいえ、主な問題は、テーブルへのデータの最初のインポートで驚くほどディスクを集中的に使用することです。MyISAM 時間: 12 分。InnoDB 時間: 3 時間以上。私の最初のロードの後、UPDATE は存在せず、INSERT はめったにありません。InnoDB の残念なロード操作に対する既知の解決策はありません。
制約とインデックスを削除し、ロード後にそれらを有効化/再構築すると、大幅に高速化される可能性があることを示唆しています-試してみたと思いますか? それは物事を改善しましたか？
適切な電力調整を備えた優れた UPS を入手してください。安定した冗長ハードウェアで実行します。
MyISAM テーブルが書き込み中のクラッシュに耐えられるとは思えないので、クラッシュ (および書き込み) の発生を減らすことが最善の策だと思います。
MySQLと結婚していますか？Postgresは (innoDB のように) ACID に準拠しており、(適切に調整されている場合) MyISAM とほぼ同じ速度です。
これは、テーブルの使用方法に大きく依存します。書き込みが多い場合は、インデックスを削除することを検討してください。これにより、回復時間が短縮されます。読み取りが多い場合は、テーブルへのすべての書き込みをシリアル化して、クラッシュ後の読み取りコピーの回復時間を最小限に抑えるレプリケーションの使用を検討することをお勧めします。
テーブルの InnoDB コピーに書き込み、MyISAM コピーにレプリケートすることができます。とにかく、MyISAM のパフォーマンス上の利点は、主に読み取り指向です。
もちろんレプリケーションを使用すると、読み取りと書き込みの間にラグタイムが発生します