同じサーバーで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で作業している他の開発者が何が起こっているかを簡単に確認できます。