1

データを表示するために、MySQL DB で PHP スクリプトを実行するように依頼されたのですが、その設計が奇妙であることに気付きました。彼らは、ユーザーごとに最大 2000 レコードを収集する必要がある調査を実行したいと考えており、登録するユーザーごとに新しいテーブルを自動的に作成しています。この段階ではパイロット スタディなので、約 30 のテーブルがありますが、実際のスタディでは 3000 人のユーザーが必要です。

それらをすべて 1 つのテーブルにまとめることを提案したかったのですが、調査期間中にそのデータベースに対して 1 分あたり約 1500 回の INSERT が発生する可能性があるため、最初にここで質問したいと思いました。これにより、MySQL でテーブル ロックが発生しますか? つまり、1 分あたり 1500 回の INSERT で最大サイズが 6,000,000 レコードの 1 つのテーブルか、1 分あたり 30 回の INSERT で最大サイズが 2000 レコードの 3000 テーブルか。最初のオプションを提案したいと思いますが、問題が発生しないことを確認したいと思います. InnoDB には行レベルのロックがあると読みました。では、1 つのテーブル オプションと組み合わせると、パフォーマンスが向上しますか?

4

1 に答える 1

0

これは非常に負荷の高い質問です。私の経験では、パフォーマンスはテーブル サイズだけで正確に測定されるわけではありません。それはデザインに帰着します。主キーとインデックスは適切に配置されていますか? インデックスされすぎていませんか?そうは言っても、ほとんどの場合、DB への 1 回のトリップは数十回よりも高速であることもわかりました。1 つのテーブル (列) の大きさは? どのような種類のデータを保存していますか (4000K より大きいですか?)。最適なパフォーマンスを確認するために、いくつかのプロトタイプを作成する必要がある場合があります。私がお勧めできる最大の方法は、収集するデータのサイズを慎重に判断してそれに応じて割り当て、インデックスを作成し (ただし、多すぎないようにし、インデックスを作成しすぎないようにしてください)、テストすることです。

于 2012-09-13T15:24:55.643 に答える