0

当社は最近フランチャイズ契約を結び、顧客に POS (キャッシュ レジスター) アプリケーションを提供しており、毎週約 3 ～ 5 件の新規登録があります。現在、新規顧客ごとにアプリケーションのデータベースの複製コピーを作成していますが、このアプローチが私たちを押しつぶす可能性があることはすでにわかっています。各テーブルの何らかの形式のクライアント ID で識別されるすべての診療所に対して 1 つのデータベースを使用するのが最善ではないかと考えていました。

ある同僚は、50,000 の大きなテーブルを使用すると処理が遅くなりすぎ、アプリケーション全体を最適化する必要があると言いました。別の同僚は、MySQL は大規模なデータベースを処理するように設計されており、各クエリの WHERE 句でクライアント ID を指定する限り、実質的に速度の変化なしにデータのサブセットを受け取ることができると述べていました。

大きなテーブル (100,000 以上) からデータのサブセットを選択すると、小さなテーブルから同じ数の行を選択する場合と速度に大きな違いはありますか?

また、データベース設計の方法についての推奨事項も大歓迎です。

4

3 に答える 3

1

データサイズはパフォーマンスに影響しますが、適切なインデックスを作成すれば、50〜100kレコードのルックアップは問題になりません。私が使用している本番データベース（約125万レコード）は、主キーでレコードを検索するのにごくわずかな時間（0.005秒未満）しかかかりません。

それでも、実際の使用方法によって異なります。クエリを最適化し、インデックスを追加しなければならない場合があります。

于 2012-06-05T14:37:39.263 に答える
0

1 つの長くて大きなテーブルではなく、いくつかの小さなテーブルに分割します。適切に設計され、インデックスが付けられていれば、長期的にはより高速になるはずです。

于 2012-06-05T14:39:13.577 に答える
0

選択 (読み取り) クエリの速度を上げるために、クエリを実行する列にインデックスを追加できます。

たとえば、ある種の診療所 ID でクエリを実行する場合、その列にインデックスを設定できます。これにより、データベースがデータをトラバースし、データベース内のすべてのレコードを調べることなく、条件に一致するレコードを見つけることができます (ここで速度低下が発生します)。将来、別の基準 (日付としましょう) でクエリを実行する場合は、その列にもインデックスを配置できます。

インデックスを追加すると実行時のパフォーマンスは向上しますが、データの格納に必要な物理ディスク サイズが増加することに注意してください。

于 2012-06-05T14:40:12.243 に答える