同じサーバーでInnoDBテーブルとMyISAMテーブルを混在させることは一般的な方法ですか？
8GBのRAMを搭載したサーバーで約4.5GBの単一のデータベースを実行しています。テーブルの大部分はMyIsam（約4.3GB）ですが、すぐに 変換する予定です それらの一部をInnoDBに変換します。 （それは最初に最も書き込み集中型のテーブルに焦点を当てて、遅いプロセスになるでしょう）。
両方のタイプのストレージエンジンが存在する専用サーバーの実行に問題はありますか？
それぞれの利点と欠点を理解している限り、同じ物理マシンで複数のストレージエンジンを使用しても、間違ったはありません。すべてのプラグインストレージタイプについて、パフォーマンスの考慮事項、機能の制限、および使用例があります。
たとえば、書き込みが90％の小さなテーブルがある場合、MyISAMを選択できます。データを簡単に再生成でき、それが小さなテーブルである場合、たとえばキューイングの場合は、メモリを選択します。読み取りが90％のテーブルがあり、データを探すときにそこにデータがなければならない場合は、おそらく、トランザクションをサポートし、InnoDBなどの構成可能な原子性をサポートするストレージエンジンを選択します。データに害を与えずにファイルシステムを介してアクセスできるようにするには、CSVを選択します。
それでも、物理ホストと同じスキーマ内で複数のストレージエンジンを安全に使用できます。
ただし、バッファがこの混乱全体に関与していることに注意してください。 MyISAMとInnoDBの両方を使用する場合は、key_bufferとinnodb_buffer_poolが競合しないように注意する必要があります。これはあなたの側で慎重な計画が必要になりますが、それは私たちがやっていることです。
これが一般的な方法かどうかはわかりません。私自身の経験についてお話します。
私はいつも仕事に最適なツールを使用しているので、いつもエンジンを混ぜています。ほとんどのプロジェクトでは、デフォルトのエンジンとしてMyISAMを使用しています。
InnoDBで利用できる特別な機能が必要な場合は、それを利用します。
テーブルがほとんど読み取り専用の場合、点滅する前にアーカイブエンジンを選択します。
マシンサーバーに十分なメモリがあることを知っていると、すべての一時データがヒープテーブルに格納されます。
私は過去にMyISAMとInnoDBが混じり合ういくつかのスローダウンを見ましたが、これは特定のMySQL問題ではありません。これは、1つのエンジンだけを使用する場合には見られない設計上の問題です。実際に間違ったエンジンを使用すると、それがMyISAMだけなのか、InnoDBだけなのか、または両方の混合なのかは関係ありません。スローダウンがいつ発生するかを知るための式を定義することは困難です。実際のテストはそれをあなたに言うことができます。
もちろん、一意のクエリでInnoDBとMyISAMを組み合わせて整合性と一貫性を維持することはできませんでした。
同じデータベースでMyISAMテーブルとInnoDBテーブルを混在させないようにしていますが、これは実用上の理由ではなく、健全性のためです。ただし、全文検索用のMyISAMテーブルを含むデータベースを用意して、サイトで実行できるようにすると便利です。各エントリの外部キーを使用して別のデータベースに保持することで、DBで作業している他の開発者が何が起こっているかを簡単に確認できます。