問題タブ [full-table-scan]

私はこのテーブルを持っています：

そしてこのインデックス：

このクエリを実行すると

EXPLAIN PLANは、完全なテーブル スキャンを実行することを示しています。そのため、インデックスを削除して再度作成しました。EXPLAIN PLANまだフルテーブルスキャンと言っています。それはどうしてですか？

背景: これは履歴データであるため、状態を含む行を検索し、状態CLEAREDを含む新しい行を挿入しますNEW(さらに、古い行からいくつかの値をコピーします)。その後、古い行が に更新されUSEDます。したがって、テーブルは常に大きくなります。私が気付いたのは、インデックスのカーディナリティが 0 であることです (何千もの異なる値があるにもかかわらず)。再作成後、カーディナリティは増加しましたが、CBO はインデックスを気に入りませんでした。

翌朝、オラクルは突然インデックスを気に入り (おそらくそれで寝ていたのでしょう)、それを使い始めましたが、長くは続きませんでした。しばらくすると、処理速度が 50 行/秒から 3 行/秒に低下し、再び「FULL TABLE SCAN」が表示されました。何が起こっている？

私の場合、約 100 万行を処理する必要があります。私は約バッチで変更をコミットします。50. インデックスを更新/再編成するためにコミット後に実行する必要があるコマンドなどはありますか?

私はOracle 10gを使用しています。

[編集] このテーブルには 969,491 個の異なるキーがあり、3 つのタイプと 3 つの状態があります。

MySQL のインデックスと非常に混同しています。

TableA1 と TableA2 の 2 つのテーブルがあります。

それらの間の結合のためにこれらにインデックスを作成しましたが、クエリは非常に高速に実行されます。

TableB1 と TableB2 など、同じ設定の別の 2 つのテーブルがあります。唯一の違いは、これらのテーブルにはいくつかの null 値があることです。

何らかの理由で、TableA に対する同じクエリは約 5 倍高速であり、テーブル全体のスキャンは必要ありません。ただし、TableB は完全なテーブル スキャンを使用しているようで、その理由がわかりません。これを引き起こしているのは Null 値でしょうか?

EXPLAIN を使用すると、TableA のセットアップで次のようになることに気付きましpossible keys: myindexたref: func。ただし、TableB のセットアップでは、possible keys: NULLとref: NULL.

私はこれについてかなり長い間検索してきましたが、関連する答えが見つからないようです。誰かが私を正しい方向に向けることができれば幸いです。

（申し訳ありませんが、元の質問に追加されました。）

ここにTableAOneがあります：

そしてTableATwo:

Field1 と Field3 を結合しています。

フルテーブル スキャンを取得するテーブルは、上記のテーブルと同じです。唯一の違いは、TableA ではなく TableB と呼ばれることです。

乾杯、
ケ

http://www.bestbrains.dk/Blog/2010/03/25/HowToAssertThatYourSQLDoesNotDoFullTableScans.aspxで説明されているのと同様のことをしたいのですが、そのためには、全表スキャンを追跡するためにpostgresが必要です。します。postgresにそのようなものはありますか？

問題

それぞれが年インデックスとステーションインデックスを持つ72の子テーブルは、次のように定義されます。

（外部キー制約は後で追加されます。）

次のクエリは、全表スキャンのために実行速度が非常に遅くなります。

鈍さは、クエリのこの部分に起因します。

クエリのこの部分は、選択した日の一致します。たとえば、ユーザーが6月1日から7月1日までのデータがあるすべての年のデータを確認したい場合、上記の句はそれらの日と一致します。使用者が12月22日から3月22日までのデータを確認する場合、データがあるすべての年について、上記の句は3月22日が12月22日の翌年であると計算するため、それに応じて日付と一致します。

現在、日付は1月1日から12月31日までに固定されていますが、上記のようにパラメータ化されます。

計画からのHashAggregateは、10006220141.11のコストを示しています。これは、天文学的に巨大な側面であると私は思います。

実行中の測定テーブル（データもインデックスもありません）で全表スキャンが実行されます。このテーブルは、子テーブルから2億7300万行を集約します。

質問

全表スキャンを回避するために日付にインデックスを付ける適切な方法は何ですか？

私が検討したオプション：

• ジン
• 要旨
• WHERE句を書き直します
• year_taken、month_taken、およびday_taken列をテーブルに分けます

あなたの考えは何ですか？

ありがとうございました！

テーブルスキャンを強制されないように、Azure Table Storage（ATS）のRowKeyまたはPartitionKey以外に対してクエリを実行しないように警告します。しばらくの間、これは私を麻痺させて、正確に正しいPKとRKを考え出し、他の何かを照会する必要があるときに他のテーブルに疑似セカンダリインデックスを作成しようとしました。

ただし、適切と思われる場合は、SQLServerでテーブルスキャンを実行するのが一般的です。

したがって、問題は、Azureテーブルをどのくらいの速度でテーブルスキャンできるかということです。これはエンティティ/秒で一定ですか、それともレコードサイズなどに依存しますか。レスポンシブアプリケーションが必要な場合、テーブルスキャンにはレコードが多すぎるという目安はありますか？

データを含むテーブルが 1 つあります。テーブルには注文のエントリがあり、各注文にはいくつかのタイプ (または、注文済み、...、研磨済み、梱包済み、出荷済みなどの状態) があります。

今、私はこのクエリを実行したいと思います。

type と shipping にはインデックスがありますが、フル スキャンを実行した後にのみ使用されます。そのため、クエリには非常に長い時間がかかります。データを直接提示したい。

私のテーブルには、インデックスのない列がいくつかあります。これらの列の値の検索には、SQLite がテーブル全体をスキャンするため、非常に時間がかかる場合があります。

私の特定のケースでは、探している行 (値は一意です) は、ほとんどの場合、最後に挿入された行の中にあります。

スキャンを実行するときにSQLiteが最も古い（最初の）行から開始すると思われます.SQLiteにテーブルスキャンを逆の順序で実行するように指示する方法はありますか?

更新:変更ログでこれを見つけました:

オプティマイザーは、そうすることが ORDER BY ... DESC 句を満たす場合、逆方向にテーブルをスキャンするようになりました。

つまり、おそらくこれは、ORDER BY 句を追加して高速化できることを意味します。

私は大きな大きなテーブル（InnoDB）を持っています。このテーブルには、基本的に場所の緯度と経度が記載された場所の名前が付いています。私のクエリは次のようなものです

唯一のインデックスは、自動インクリメント列のプライマリインデックスです。

InnoDBを使用したいので、FULLTEXTはオプションではありません

私が試したオプションの1つは、緯度と経度にインデックスを追加して、

それから私はします

ただし、$ resultには数千のエントリが含まれる可能性があり、メモリを大量に消費するため、拡張性はあまり高くありません。

今のところ、私は全表スキャン（上記の最初のクエリ）に頼っていますが、クエリごとに0.5〜1秒かかるので、助けていただければ幸いです。

ありがとう

私はこのテーブル（TableA）を持っています：

明確なFieldA値はほとんどありません。たとえば、FieldAを{1,2,3,4,5,6}にすることができます。

このクエリによって全表スキャンが発生するのはなぜですか。

これはしませんが：

SQL Serverはこれを最適化できませんか？FieldAがPKであるTableBがあり、TableBとTableAを結合した場合、クエリは2番目のクエリと同様に実行されます。

私は現在、ユーザー データの増分更新の戦略を開発しています。データベースには 100_000_000 レコードがあり、ワークフローごとに約 1_000_000 レコードが更新されると想定しています。

アイデアは、MapReduce ジョブでレコードを更新することです。現在のレコードにランダムにアクセスできるようにするために、インデックス付きストレージ (Cassandra など) を使用すると便利ですか? または、HDFS からデータを取得し、新しい情報を既存のレコードに結合することが望ましいですか。

レコードサイズはO(200バイト)です。ユーザー データは固定長ですが、拡張可能である必要があります。ログ イベントの構造は似ていますが、同じではありません。ユーザー レコードの数は増加する可能性があります。ほぼリアルタイムの更新が望ましいです。3 時間のタイム ギャップは許容できません。数分でも問題ありません。

これらの戦略とこのサイズのデータ​​のいずれかを使用した経験はありますか? 豚のJOINは十分に速いですか？すべてのレコードを読み取ることが常にボトルネックですか? Cassandra はこの量のデータを効率的に保持できますか? スケーラブルなソリューションはどれですか? システムの複雑さはどうですか？