0

すべての顧客の特定の更新を格納するテーブルがあります。

いくつかのサンプルテーブル:

record_id | customer_id | unit_id | time_stamp | data1 | data2 | data3 | data4 | more

アプリケーションを作成したとき、このテーブルがどれだけ大きくなるかわかりませんでした。現在、1 か月以内に 1000 万件を超えるレコードがあります。時間がかかるためにphpが実行を停止すると、問題に直面しています。一部のクエリは、time_stamp+ customer_id+unit_id

この種の問題にどのように対処することをお勧めしますか? たとえば、顧客ごとに新しいテーブルを作成できますが、それは良い解決策ではないと思います。

良い解決策が思い浮かびません。

4

3 に答える 3

1

クラウド上にいる場合 (サーバーとデータベース間でデータを移動するために課金される場合)、無視してください。

すべてのロジックをサーバーに移動

最速のクエリはSELECT WHERE、PRIMARY. データベースがどれほど大きいかは問題ではありません。1 行のテーブルでも同様に高速に戻ります (ハードウェアのバランスが崩れていない限り)。

クエリで何をしているのか正確にはわかりませんが、最初にすべての並べ替えデータと制限データを PHP にダウンロードします。必要なものを手に入れたらSELECT、データは直接WHEREオンになりますrecord_id（それがあなたのものだと思いますPRIMARY）。

オンデマンド データはかなり計算集約的で巨大なようです。そのため、より高速な言語を使用することをお勧めします。 http://blog.famzah.net/2010/07/01/cpp-vs-python-vs-perl-vs-php-performance-benchmark/

また、データベースではなくサーバーで並べ替えと制限を開始すると、ショートカットを特定してさらに高速化できます。

これがサーバーの目的です。

于 2013-02-15T02:24:55.660 に答える
1

いくつかの基準に従って、データのパーティション分割を使用することをお勧めします。

データを水平または垂直に分割できます。

たとえば、id モジュール 10 を使用して、customer_id を 10 個のパーティションにグループ化します。

したがって、0 で終わる customer_id はパーティション 0 に移動し、1 で終わるとパーティション 1 に移動します

MySQL はこれを簡単に作成できます。

于 2013-02-15T02:03:09.690 に答える
0

テーブル内のレコード数は? 多くの場合、リレーショナル データベースでは、所有しているデータの量ではなく (リレーショナル データベースでは何百万もありません)、データを取得する方法が問題になります。

実際、選択の外観からすると、おそらくステートメント自体を最適化し、複数の副選択を回避する必要があるだけであり、これがおそらく速度低下の主な原因です。そのステートメントで Explain を実行するか、ID を取得して、最初の実行で実際に見つけて取得したレコードの ID に対して内部選択を個別に実行してみてください。

全体的なステートメント内にこれらのサブセレクトがあるという事実は、いずれにせよ、プロセスをそこまで最適化していないことを意味します。たとえば、によって作成されたようなセットを新しいテーブルに集約する毎晩または毎時の cron ジョブを実行している場合、以前に生成されSELECT gps_unit.idgps_unitたテーブルに対して選択を実行することができます。その場でテーブル。

その選択ステートメントを効果的に最適化できない場合は、次のような「最終的な」オプションがあります。

  • いくつかの基準で分類し、別のテーブルに分割します。
  • 最初の 1 年ほどを過ぎたものはあまり使用されていないテーブルに移行され、特別な検索が必要になるように、深いアーカイブを保持します。
  • 最後に、非常に小さなデータがある場合は、特定のテーブルを完全にアーカイブしてファイル形式のみで保持し、特定の日付を過ぎて切り捨てることができる場合があります。それほど重要ではなく、スパムのような Web 追跡データを使用することがよくありますが、数年後、データが実際には何の役にも立たなくなったときに、これを行うことになります。
于 2013-02-15T02:02:52.490 に答える