私は現在、130のMySQLテーブルをすべてMyISAMストレージエンジンで使用しているアプリケーションを持っています。すべてのテーブルには、選択/挿入/更新/削除クエリを含む毎秒複数のクエリがあるため、データとインデックスは常に変化しています。
私が直面している問題は、ハードドライブが対応できないことです。MySQLによって非常に多くの読み取り/書き込みが行われるため、I/Oアクセスの待機時間が最大6秒以上になります。
1つのテーブルに変更して、メモリベースにすることを考えていました。クエリが多いものにメモリテーブルを使用したことは一度もないので、それが正しいことかどうかについて誰かがフィードバックをくれるかどうか疑問に思っています。
1つの可能性は、パフォーマンスの問題を引き起こす他の問題がある可能性があることです。複雑なデータベースであっても、CRUD操作には6秒が長すぎるようです。（当時）ArsDigitaは、かなり控えめなディスク構成の双方向Sun Ultra 2（IIRC）で1秒あたり30ヒットを処理できることを覚えておいてください。賢明なディスクレイアウトと適切なチューニングを備えた最新の中低域サーバーは、かなりの作業負荷に対処できるはずです。
インデックスがありませんか？-遅いクエリのクエリプランで、あるべきではないテーブルスキャンを確認します。
サーバー上のディスクレイアウトは何ですか？-ハードウェアをアップグレードする必要がありますか、それともディスク構成の問題を修正する必要がありますか（ディスクが足りない、データと同じボリュームにログオンするなど）。
他のポスターが示唆しているように、頻繁に記述されたテーブルでInnoDBを使用することをお勧めします。
データベースサーバーのメモリ使用量の設定を確認してください。より多くのキャッシュを構成することをお勧めします。
編集：データベースログは、独自のクワイエットディスクに保存する必要があります。それらは、多くの小さなシーケンシャル書き込みを伴うシーケンシャルアクセスパターンを使用します。データファイルのようにランダムアクセスの作業負荷でディスクを共有する場合、ランダムディスクアクセスはログに大きなシステムパフォーマンスのボトルネックを作成します。これは完了する必要がある（つまり、物理ディスクに書き込まれる）書き込みトラフィックであるため、キャッシュはこれに役立ちません。
MEMORY テーブルに変更したところ、すべてが改善されました。実際、サーバー上に予備のリソースが追加され、運用をさらに拡張できるようになりました。
あなたのデータベース構造は非常に間違っており、最適化する必要があり、ストレージとは何の関係もないと思います
innodb を使用していない特定の理由はありますか? キャッシングと異なる同時実行モデルにより、パフォーマンスが向上する場合があります。より多くの調整が必要になる可能性がありますが、はるかに優れた結果が得られる可能性があります。