問題タブ [sql-tuning]

「count( ) over()」は「select count( ) from table」よりもはるかに高速であることがわかりました。

例えば

count( *) オーバーを使用

with CTE as( select col_A,col_B,totalNumber=count(*) over() from table1 where conditions..) select totalNumber from CTE

select count( *) from を使用 (または count(1) も使用)

select count(*) from table1 where conditions..

SQL Server 2K5でのローカル テストでは、count( ) over* は、検索条件が複雑で、返される行が大きい場合、4 倍速くなります。

しかし、count(**) のオーバー パフォーマンスがこれほど高速なのはなぜでしょうか。

前もって感謝します。

ヴァンス

アップデート

私は本当にいくつかの詳細を見逃したと思います：

実際には、次のようなテストに「ステートメントの準備」SQLを使用します。

exec sp_executesql N'SELECT count(*) FROM tableA WHERE (aaa in(@P0)) AND (bbb like @P1)', N'@P0 nvarchar(4000),@P1 nvarchar(4000)',N'XXXXXXX-XXXX-XXX',N'%AAA%'

Execution Plan says "HashMatch" cost 61%, others is "index seek". And the execution time will be 1484ms and logical reads around 4000.

これは、

SELECT count(*) FROM tableA WHERE (aaa in('XXXXXXX-XXXX-XXX')) AND (bbb like '%AAA%') Execution plan says "clustered index seek" cost 98%. And the execution time is 46ms and logical reads will be 8000.

そして、最初のSQLを次のように変更した場合:

exec sp_executesql N'with CTE as( SELECT total=count(*) over () FROM tableA WHERE (aaa in(@P0)) AND (bbb like @P1)) select top 1total from cte', N'@P0 nvarchar(4000),@P1 nvarchar(4000)',N'XXXXXXX-XXXX-XXX',N'%AAA%' Execution plan says "clustered index seek 58%', no "hashmatch join" occurs.

And the execution time is 15ms and logical reads is: 8404.

それで、「ハッシュマッチ結合」はパフォーマンスに多くのオーバーヘッドがありますか?

次のクエリは、ユーザーによる未読メッセージのリストを受信することを目的としています。これには3つのテーブルrecipientsが含まれます。ユーザーとメッセージIDの関係messages、メッセージ自体、およびmessage_readersどのユーザーがどのメッセージを読んだかを示すリストが含まれます。

クエリには確実に4.9秒かかります。これはパフォーマンスに深刻な悪影響を及ぼします。データベースが最終的に数桁大きくなることを期待しているため、特に心配です。確かに、これは本質的に重いクエリですが、データセットは小さく、直感的にははるかに高速であるように見えます。サーバーには十分なメモリ（32GB）があるため、データベース全体を常にRAMにロードする必要があり、ボックス上で他に何も実行されていません。

テーブルはすべて小さいです：

クエリ自体：

説明計画は非常に簡単です。

にインデックスがありmessage_readers.read_by_idますが、IS NULL条件のため、実際には使用できないと思います。

以下を除くすべてのデフォルト設定を使用しています。

ありがとう！

Oracle DB への次のクエリを確認して、何が問題なのかを指摘してください。

クエリ統計:

• かかった時間: 10.53 秒。

指標:

• t2.empnoインデックスされています。

• t1.idインデックスされています。

• t2.idインデックスされています。

アップデート

上記のクエリは、私が使用するクエリの単なるサンプル レプリカです。以下、より正確な形で

計画の説明

クエリ:

索引付けされた列:

テーブル

表 2

Merge join CARTESIAN は常に危険ですか?

コストが 7 から 40 の範囲のクエリが多数ありますが、実行にはマージ結合デカルトに従います。

クエリのコストが低い場合、マージ結合デカルトについて本当に気にする必要がありますか?

これについて本当に助けが必要です。

どんな助けでも大歓迎です。

ありがとう、サビサ

私はOracle 10gR2に取り組んでいます

テーブル TBL_CUSTOMER の MERGE ステートメントがあります。TBL_CUSTOMER には、メール アドレスを含む列 USERNAME が含まれています。このテーブルに格納されているデータは、大文字、小文字、または大文字と小文字の任意の組み合わせを受信データに使用できるため、大文字と小文字が区別されません。

データをマージするときは、大文字と小文字を区別せずにデータを比較する必要があります。UPPER(USERNAME) として USERNAME 列に関数ベースのインデックスを作成しました。

実行計画を確認すると、USERNAME の関数ベースのインデックスが使用されていません。OR 条件を削除すると、インデックスが使用されることに気付きましたが、ビジネス ロジックが複雑なため、それを削除することはできません。

そのインデックスを強制的に使用するにはどうすればよいですか?

MySQL プラットフォームで次の SQL クエリを実行します。

テーブル A は、1 つの列 (主キー) と 25K 行を持つテーブルです。テーブル B には、いくつかの列と 75K 行があります。

次のクエリの実行には 20 分かかります。お役に立てれば幸いです。

ステージング テーブルから入力を受け取り、それらの行をキューブに追加する OWB マッピングがあります。キューブの背後にある基になるテーブルは、外部キーを使用してディメンションと結合されたリレーショナル ファクト テーブルです。クエリの背後にある Explain Plan のコストはかなり高く、マッピングは 30 分間実行されます。以下に示すように、ステップ 17 でコストが 1,396,573 まで上昇し、ネストされたループが表示され始めます。誰かがこのクエリを調整するための一般的な指針を提供できますか?

プラン

2 つのテーブルがあり、1 つには ID <-> 名前マッピングが含まれ、もう 1 つのテーブルには複数の ID 列が含まれています。対応する ID の名前を持つ 2 番目のテーブルのレコードを一覧表示するには、次のようなクエリを実行します。

これがそれを行う唯一の方法でしょうか？2 番目のテーブルは、すべての行のすべての ID 列に対してクエリが実行されるためです。

クエリで 2 ～ 3 個を超えるテーブルを結合する場合、すべてのテーブルに共通の列がある場合、パフォーマンスに違いはありますか?

1. すべてのテーブルの共通の列に値を指定します。

   例：

   /li>

2. 共通の列の 1 つに値を与え、他の列と結合する

   例：

   /li>

この質問をする理由は、例 1 のように値を指定すると実行されるクエリ (コストは 17) がありますが、例 2 のように列を結合するとハングして実行されないためです。

これを理解するのを手伝ってください。