1つの可能性は、パフォーマンスの問題を引き起こす他の問題がある可能性があることです。複雑なデータベースであっても、CRUD操作には6秒が長すぎるようです。 （当時）ArsDigitaは、かなり控えめなディスク構成の双方向Sun Ultra 2（IIRC）で1秒あたり30ヒットを処理できることを覚えておいてください。賢明なディスクレイアウトと適切な調整を備えた最新の中低域サーバーは、かなりの作業負荷に対処できるはずです。
-
インデックスがありませんか？ -遅いクエリのクエリプランをチェックして、テーブルスキャンを行うべきではない場所を探します。
-
サーバー上のディスクレイアウトは何ですか？ -ハードウェアをアップグレードする必要がありますか、それともディスク構成の問題を修正する必要がありますか（ディスクが足りない、データと同じボリュームにログオンするなど）。
-
他のポスターが示唆しているように、頻繁に記述されたテーブルでInnoDBを使用することをお勧めします。
-
データベースサーバーのメモリ使用量の設定を確認してください。より多くのキャッシュを構成することをお勧めします。
編集： データベースログは、独自のクワイエットディスクに保存する必要があります。それらは、多くの小さなシーケンシャル書き込みを伴うシーケンシャルアクセスパターンを使用します。データファイルのようにランダムアクセスの作業負荷でディスクを共有する場合、ランダムディスクアクセスはログに大きなシステムパフォーマンスのボトルネックを作成します。これは完了する必要がある（つまり、物理ディスクに書き込まれる）書き込みトラフィックであるため、キャッシュはこれに役立ちません。