1

Amazon RDS インスタンスに 250,000 行の MySQL テーブルがあります。しようとすると

SELECT * FROM  tableName

条件なし (テストのためだけに、通常のクエリは必要な列を指定しますが、ほとんどの列が必要です)、クエリの実行には 20 ～ 60 秒かかります。これがレポートのベース クエリになり、レポートは 60 秒以内に実行されるはずなので、うまくいかないと思います (結合を追加した瞬間にタイムアウトになります)。レポートは、小規模なテスト環境では問題なく実行されます。

MySQL がテーブルをロックしようとして、すべての書き込みが完了するのを待っているため、クエリに非常に時間がかかっている可能性がありますか? このテーブルにはかなり多くの書き込みがある可能性があります。本番システムをクエリでロックアップしたくないので、MySQL スレーブでクエリを実行しています。

  • リレーショナル DB の行数については経験がありません。〜30列（varchar、date、およびinteger型）の250 000行は多いですか？
  • このクエリを高速化するにはどうすればよいですか (ハードウェア、ソフトウェア、クエリの最適化 ...)
  • データが矛盾していてもかまわないことを MySQL に伝えることはできますか (これはレポート データベースからのスナップショットです)。
  • このクエリが 60 秒未満で実行される可能性はありますか? それとも目標を調整する必要がありますか?
4

5 に答える 5

2

250,000 行のテーブルは、MySQL にとっては大きすぎません。

ただし、それらの行がアプリケーションに返されるのを待つには時間がかかります。それはネットワーク時間であり、おそらくあなたと Amazon の間には多くのホップがあります.

レポートが実際にすべてのデータを処理する場合を除き、次のような単純なクエリを使用してデータベースのパフォーマンスを確認してください。

select count(*) from table;

編集：

問題がデータベースに起因する可能性は低いです。これは、ネットワーク トラフィックが原因である可能性があります。別の回答で述べたように、ストリーミングは問題を解決する可能性があります。また、データ形式をいじって、合計サイズをより妥当なものにすることもできます。

最後の手段は、データをテキスト ファイルに保存し、ファイルを圧縮して移動し、解凍することです。これは大変な作業のように思えますが、データを 5 倍から 10 倍に圧縮することで、送信にかかる時間を大幅に節約し、残りの処理でパフォーマンスを大幅に向上させることができます。

于 2013-08-27T15:20:14.177 に答える
1

私はクライアントから更新された仕様を入手し、返されるユーザーの数を 250 に減らすことができました。

したがって、おそらく答えは次のとおりです。クエリでテーブル全体をダンプするのではなく、必要な正確なデータのみをフェッチしてください。クライアントには SQL アクセス権があり、クエリを更新する必要があるため、関連するユーザーのみが返されます。

于 2013-08-28T08:02:34.947 に答える
0

* をワイルドカードとして使用するべきではありません。実際に必要なフィールドを選択し、これらのフィールドを組み合わせてインデックスを作成します。

于 2013-08-27T15:19:36.820 に答える