3

私はデータベースに取り組んでおり、13億行、約35列のかなり大きなデータベースに取り組んでいます。テーブルのステータスを確認した後、次のようになります。

Name:Table Name
Engine:InnoDB
Version:10
Row_format:Compact
Rows:12853961
Avg_row_length:572
Data_length:7353663488
Max_data_length:0
Index_length:5877268480
Data_free:0
Auto_increment:12933138
Create_time:41271.0312615741
Update_time:NULL
Check_time:NULL
Collation:utf8_general_ci
Checksum:NULL
Create_options:
Comment:InnoDB free: 11489280 kB

私が直面している問題は、単一の選択クエリでも処理に時間がかかりすぎることです。たとえば、クエリ Select * from Table_Name limit 0,50000には約2.48分かかります。

履歴データ全体、つまり13億行全体を使用する必要があるレポートを作成する必要があります。このバッチをバッチごとに実行することはできますが、その場合、何度も何度も時間がかかりすぎるクエリを実行する必要があります。

単純なクエリに非常に時間がかかる場合、結合とケースステートメントを必要とする他の複雑なクエリを実行できません。

4

6 に答える 6

7

一般的な方法は、大量のデータがある場合、...

  1. すべきではないSELECT *:必要な列のみを選択する必要があります
  2. フェッチ範囲をより少ない数に制限する必要があります。50000レコードを同時に処理することはないと思います。バッチごとにフェッチしてみてください。
于 2012-12-28T09:57:50.077 に答える
1

多くのデータベース管理者が直面する一般的な問題。解決策:キャッシング

クエリをより単純で小さなクエリに分割します。Memcachedまたはその他のキャッシュ技術とツールを使用するMemcachedはキー値のペアを保存し、memcache内のデータを確認します。利用可能な場合はそれを使用します。データベースからそれをフェッチしない場合は、使用してcachします。次に、データはcaheから入手できます。

独自のロジックを開発し、いくつかのクエリを変更する必要があります。Memcachedはここから入手できます:

http://memcached.org/

多くのチュートリアルがWebで利用可能です

于 2012-12-28T09:57:41.543 に答える
1

my.confで最大N秒の遅いクエリを有効にしてから、いくつかのクエリを実行してこのログを監視します。これにより、いくつかの手がかりが得られ、このテーブルにいくつかのインデックスを追加できます。

または、EXPLAINを使用していくつかのクエリを実行します。http://hackmysql.com/case1

于 2012-12-28T10:04:34.733 に答える
0

通常は簡単な勝利である簡単なメモ...

大きなテキストブロブである列がある場合は、それらのフィールドを除くすべてを選択してみてください。varchar(max)フィールドがクエリの効率を完全に損なうのを見てきました。

于 2013-01-06T04:25:23.027 に答える
0

非常に広い平均行サイズと35列があります。テーブルを垂直に分割することを試みることができます。つまり、テーブルを、テーブルの列のサブセットと1:1で相互に関連する小さなテーブルに分割します。InnoDBは行をページに格納するため、非常に幅の広い行には効率的ではありません。

データが追加専用の場合は、ICEの確認のみを検討してください。

優れた圧縮をサポートしているTokuDBもご覧ください。

パーティショニングとShard-Query(http://code.google.com/p/shard-query)を使用してデータに並行してアクセスすることを検討できます。Shard-Queryを使用して、並列処理のためにデータを複数のサーバーに分割することもできます。

于 2013-05-22T07:51:29.757 に答える
-2

WHERE句を追加してみてください。WHERE1 =1 効果がない場合は、エンジンタイプをMyISAMに変更する必要があります。

于 2012-12-28T09:53:26.823 に答える