問題タブ [full-table-scan]

メッセージ列に 3,090,590 行あり、このコードを使用して一度に 3000 行を取得しています。

SQL を NoSQL に変換しようとしています。このため、Ajax で PHP スクリプトを作成しました。Ajax リクエストは$page毎回乗算されます。たとえば、3000、9000、12000...

どういうわけか、クエリを制限しても、常にテーブル全体をスキャンするため、MySQL は使用可能な CPU を 100% 使用します。すべての列に完全なインデックスを作成していますが、それでも非常に遅いです。

最適化する方法を教えてください。

TOAD を開いて実行するselect * from tableと、結果 (最初の 500 行) がほぼ瞬時に返されます。しかし、Explain Plan は完全なテーブル スキャンを示しており、テーブルは非常に巨大です。こんなに早く結果が出るなんて。

私は3つのテーブルを持っています（すべてと実際のフィールド名を書いているわけではありません）

• 契約（〜30000行）

  | id | client_id | Contract_nr|...。

• コンテナ（〜30000行

  | id | Contract_nr | phone_1（varchar）|...。

• クライアント（〜35 000行）

  | id | phone_2（varchar）| phone_3（varchar）| phone_4（varchar）|...。

電話番号を検索する必要があるので、これを試してみます。たとえば、container.phone_1で1つの電話番号を検索する場合

しかし、ORを使用してクライアントから電話番号を追加し始めたとき

説明の拡張：

テーブルの結合に使用され、検索に使用されるすべてのフィールドにインデックスを付けました。また、すべての検索行が含まれているクライアントテーブルとコンテナテーブルの複数列のインデックスを作成しようとしましたが、違いはありません。

コンテナテーブルの32113行のスキャンを回避するにはどうすればよいですか？

クエリに時間がかかる理由を理解しようとしているので、最適化できます。

EXPLAINで試してみました：

これをWorkbenchで実行すると、接続のエラーコードが10分（600秒）後に失われます。Indexinを設定した後Prod_ID、クエリは約1秒（完全）で応答します。それ以前は、応答を取得することはほぼ不可能でした。またEXPLAIN PLAN、数秒で実行できます。それでも、インデックスを使用する前に、クエリでEXPLAINを使用したいと思います。

ここに何かアイデアはありますか？

ここでこれを見つけました：

一般に、次のいずれかの状況では、列にインデックスを作成することを検討してください。

• 1 つまたは複数のインデックス付きの列に参照整合性制約が存在します。インデックスは、親テーブルの主キーを更新したり、親テーブルにマージしたり、親テーブルから削除したりする場合に必要となる完全なテーブル ロックを回避する手段です。

このような状況でテーブル全体のロックが発生する理由がわかりません。親テーブルの主キーを削除/更新しようとすると、子テーブルで完全なテーブルスキャンが実行されると思いました。

ロックはどこから来るのですか？

私は現在、すべてのシステムで公正な実装を実現するために、抽象的なデータ モデルと抽象的なクエリに基づいて SQL データベースと NoSQL データベースを比較するベンチマーク (これは私の学士論文の一部です) に取り組んでいます。

私は現在、次のように指定されたクエリの実装に取り​​組んでいます: 次のように指定された Cassandra のテーブルがあります。

このテーブルには、約 100,000,000 レコード (~300GB) が含まれています。

report_name、view_name、col_name、およびrow_nameのすべての可能な組み合わせについて、フィールド「金額」の合計を計算する必要があります。

SQL では、これは非常に簡単です。合計 (金額) を選択し、必要なフィールドでグループ化するだけです。ただし、Cassandra はこれらの操作をサポートしていないため (まったく問題ありません)、別の方法でこれを実現する必要があります。

現在、私はこれを実現するために、テーブル全体のウォークを実行し、各レコードを処理し、組み合わせごとに Java の HashMap に合計を格納しています。私が使用する準備済みステートメントは次のとおりです。

これは、cassandra と Java アプリの両方で大量の RAM を搭載したマシンでは部分的に機能しますが、小規模なマシンではクラッシュします。

今、これをより速い方法で達成できるかどうか疑問に思っていますか? cassandra パーティション キーとしても機能する partition_key を使用して、すべてのパーティションに対してこれを行うことを想像できます (5 つ持っています)。

また、すべてのパーティションとレポートを個別のスレッドに割り当てて並列に実行することにより、これをマルチスレッド化することも考えました。しかし、これはアプリケーション側で多くのオーバーヘッドを引き起こすと思います。

実際の質問に移りましょう: これを達成するために別の実行戦略をお勧めしますか? たぶん、私はまだ SQL のように考えすぎているのかもしれません。

ご支援ありがとうございます。

1,000 万行未満の大きな mysql テーブルがあるとします。

すべての結果を選択したい場合は、明らかに完全なテーブル スキャンが正常に機能します。

しかし、それを並行して行う方法は？Sqoop で解決策が見つかりましたSplit。

問題は、id size number大きな mysql がそれをFull table scan.

Update1 : スロー クエリ ログ

Update2：説明

Update3 : Mysql バージョン

そして、そのようなクエリを 3 つ同時に送信すると、サーバーのクエリ時間が長くなり、耐えられなくなります。

では、分割クエリを並行して実行することは可能ですか? そうでない場合、なぜ Sqoop はこのようなことをするのでしょうか? どうも。

サイズが約 3 GB の SQLite3 DB があります。特定の製品の最新の注文を 2 つの日付の間に表示するためにクエリを実行しようとしています。

テーブルの作成に使用されるクエリは次のとおりです。

テーブルに重複がないことを確認するために、ProductIDとにインデックスを作成しました。OrderDateTime

これを行うために現在使用しているクエリは次のとおりです。

そのクエリは正常に機能し、まさに私が望むことを行いますが、クエリの「a」部分についてテーブル全体をスキャンしているようです。私のトレースは次のとおりです。

実行に少なくとも 2 分かかるため、操作できません。構造でProductIDが主キー 1 としてOrderDateTime表示され、 が主キー 2 として表示されていることに気付きましたが、これが理由でしょうか?