問題タブ [full-table-scan]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
performance - Hive フル テーブル スキャンの問題 (パーティション化された列を使用)
Hive 0.13 に BIG テーブルがあります。1 日あたり約 250 GB のデータがあります。したがって、1 時間あたり、約 10 GB のデータになります。BI ツールが生成して Hive で実行するクエリをテストするために、1 日または 1 時間ごとにこのテーブルのデータにアクセスしたい BI ツールがあります。
BI が昨日の日次データに使用されるクエリの 1 つは、次のようになります。
MY_TABLE の Hive の My Table であり、YYYY、MM、および DD は MY_TABLE のパーティション分割された列です。すでに ORC 形式で保存されています。
上記のクエリは非常に長い時間実行されます.EXPLAIN EXTENDED出力を見ると、フィルター条件に関係なくMY_TABLEのFULL TABLE SCANを実行していることがわかります.
どうすればこの問題を回避できますか?
親切なアドバイス。
再度注意してください: Hive のバージョンは 0.13 です。アップグレードの途中です。
ありがとう、
スッダサトワ
ノート:
ここで提供されている解決策 (このクエリでパーティションの削除が行われないのはなぜですか? ) は私の場合には適用できません。なぜなら、私は Hive 0.13 を使用しているのに対し、CURRENT_DATE 関数は Hive バージョン 1 以降でしか使用できないからです。
mysql - mysql での全テーブル スキャン
select *from REPT_AIR_PRY_HY1 RAP where
(RAP.DATE_OF_ISSUE) BETWEEN "2017-10-01" AND DATE_ADD("2017-10-31", INTERVAL 1 DAY)
このクエリの説明計画では337243 が得られますが、これらの日付の間のデータは55209しかなく、列 DATE_OF_ISSUE にインデックスが作成されることさえあります。では、なぜテーブル全体をスキャンしているのでしょうか? 前もって感謝します
mysql - キーが利用可能な場合のMySQLクエリの全テーブルスキャン
いくつかの結合されたテーブルから多数の一連の列 (〜 15-20) を取得しようとして、必要な情報を取得する 2 つのビューをまとめました。ただし、私のローカル DB (〜 1kposts
行のみ) では、これらのビューの結合は正常に機能しました。実稼働 DB (~30kposts
行) で同じビューを作成し、ビューに参加しようとしたとき、そのソリューションはテスト データセットを超えて拡張できないことに気付きました。
これらの 2 つのビュー (カテゴリ データ —categories.title
などusers.display_name
) を CTEに移行しようとしましたpost_data
。これは、理論的には、これらのビューのキー付きバージョンとして機能し、適格な投稿のすべての投稿データを取得できるようにします。 .
テーブル構造を説明するために、サンプルDBFiddleといくつかのテスト データをまとめました。実際のデータにはさらに多くの列がありますが、これはクエリを作成するために必要な結合を表しています。
以下のクエリでは、適格な投稿は base で決定されSELECT
ます。次に、post_data CTE が結果セット (25 行に制限) に結合され、CTE のすべての列が返されます。
理論的には、基本選択基準に基づいて行を選択し、投稿 ID に基づいて CTE のインデックス スキャンを実行することで、これが機能すると考えました。ただし、クエリ オプティマイザーは代わりに、テーブルのフル テーブル スキャンを実行することを選択しているようですposts
。
から次のEXPLAIN SELECT
情報が得られました。
posts
これを超えて、クエリをリファクタリングして、選択で使用するなど、テーブルでのキーの使用を強制しようとしFORCE INDEX(PRIMARY)
ましたが、CTE をベースクエリに移動してフィルターを追加しましたWHERE id IN ({the original base query})
が、オプティマイザーはまだ完全なテーブルスキャンを行っているようです。
クエリプランで何が起こっているかを解読すると役立つ場合:
- 執筆時点では33,387
posts
行ありますが、クエリ プランでは - クエリ プランは、 33,870行を返すフル テーブル スキャンを示しています。
- クエリ プランでは、派生テーブル (
<derived2>
) が493,911行あることも示されています。
私の主な質問は次のとおりです。
ベース選択クエリからの結果行ごとにサブクエリを 1 回だけ実行する必要があると言うのは正しいですか? もしそうなら、CTEはJOINも使用し
posts.id
、おそらくテーブルインデックスを使用する必要がありますか?33,387行しかないのに、クエリ プランで33,870行が選択されるのはなぜですか? そして、493,911 行はどこから来るのでしょうか?
この場合、全表スキャンをどのように防止しますか?