問題タブ [query-hints]

更新: EF の将来のバージョンでヒント コントロールを実装するための提案を作成しました。ここに行って投票してください。

Entity Framework (EF) クエリの 1 つが Sql Server で実行するのに非常に長い時間がかかるという問題がありますが、生成された TSQL をコピーして Sql Server Management Studio (SSMS) に貼り付けると、非常に高速に実行されます。調査の結果、パラメーター スニッフィングの問題が発生していることがわかりました。これを修正する正しい方法は、多くのクエリ ヒント (OPTIMIZE FOR、RECOMPILE など) の 1 つを挿入することです。これらのヒントを EF クエリに挿入するにはどうすればよいですか?

さまざまな観点からの関連する質問は、ここ、ここ、およびここにあります。

どのテナントが照会されているかによって、非常に異なる数の行を返すマルチテナント データベースがあります。最近、1 つのテナント (TenantID = 1) に対して実行された Entity Framework (EF) クエリが、別のテナント (TenantID = 2) に対して同じクエリよりもはるかに長くかかる、パラメーター スニッフィングの問題が発生しています。私はいくつかの調査を行った結果、EF は毎回クエリを強制的に再コンパイルできるようにするクエリ ヒント (この質問を参照) をサポートしていないと判断しました。今、EF によって生成された Sql クエリをインターセプトし、実行前に「OPTION (OPTIMIZE FOR UNKNOWN)」を手動で追加できるかどうか疑問に思っています。これは可能ですか？生成された Sql を実行前に変更できるように、EF はプラガブルですか? これを行う方法の例はありますか?

Oracle データベース サーバーで実行するステートメントがあります。ステートメントには約 5 つの結合があり、異常はありません。以下のように見えます。

問題 (そして興味深い点) は、userid = 1 のステートメントが 590 レコードを返すのに 1 秒かかることです。userid = 2 のステートメントは、70 レコードを返すのに約 30 秒かかります。

なぜこんなに差が大きいのか理解できません。

userid = 1 の文と userid = 2 の文では異なる実行計画が選択されているようです。

Oracle Hint FIRST_ROW を実装した後、パフォーマンスが大幅に向上しました。両方のステートメント (ID 1 と 2 の両方) は、1 秒未満でリターンを生成します。

質問:

1. userid = 2 (ヒントが使用されていない場合) の場合にパフォーマンスが低下する理由として考えられるものは何ですか?
2. あるステートメントと別のステートメントで実行計画が異なるのはなぜですか (ヒントが使用されていない場合)。
3. このヒントをクエリに追加する際に注意すべきことはありますか?

共有モードでテーブル全体をロックする必要があります。「select 1 from (select * from mytable lock in share mode) t where 1=2」のようなものを実行すると、クエリ オプティマイザーはネストされたサブクエリを削除し、基本的にクエリをノーオペレーションにしますか? 私の簡単な実験では、そうではありません (これが私が必要としているものです)。単なる事故ではなく、設計上の動作によって予期されているのではないかと思います。テーブル全体をロックする他の方法はありますか? 注：「LOCK TABLE READ」は使用できません。最初に解放しないとWRITEロックに昇格できないようです。

MySQL バージョン: 5.1.50 および 5.5.27。

システムには、使用している論理読み取りの量に問題があるクエリがあります。クエリは頻繁に (1 日に数回) 実行されますが、本質的にレポートです (つまり、データを収集するため、トランザクションではありません)。

数人に見てもらった後、いくつかの異なるオプションを検討しています。

1. OPTION (FORCE ORDER) といくつかの MERGE JOIN ヒントを使用して、オプティマイザーがデータをより効率的に処理できるようにします (少なくともテスト済みのデータでは)。

2. 一時テーブルを使用してクエリを分割し、オプティマイザーが非常に大きなクエリを処理しないようにして、より効率的に処理できるようにします。

スキーマの大幅な変更などを行うオプションは実際にはありません。クエリのチューニングは、この問題の集結点のようなものです。

クエリ ヒント オプションのパフォーマンスは他のオプションよりも若干優れていますが、現時点ではどちらのオプションもパフォーマンスの観点からは許容範囲内です。

そこで問題は、あなたはどちらが好きですか? クエリ ヒントは、オプティマイザーなどをオーバーライドしているため、少し危険と見なされます。一時テーブル ソリューションは、tempdb などに書き出す必要があります。

過去に、大規模なレポート クエリで一時テーブルを使用して大幅なパフォーマンスの向上を確認できましたが、これは一般的に、このクエリよりも実行頻度の低いクエリの場合に見られました。

テーブルにデータを挿入するときに、SQL Server で ROWLOCK オプションを使用したいと考えています。それは何らかの形で役立ちますか。データベースのブロックを減らすのに役立ちますか?

SQL Server 2008 DB (通常の分離レベル) で同時に読み書きされるテーブルがあります。

同僚の 1 人は、そのテーブルに対する選択クエリで (updlock) を使用したクエリ ヒントがデッドロックを減らすかどうか疑問に思っていましたが、これをどうすればよいかよくわかりません。

通常の共有読み取りロックがタイムアウトを引き起こす場合、その状況では更新ロックもデッドロックを引き起こすと思いますか?! または、何か不足していますか？

皆さんありがとう！

SQL Server 2008 R2（バージョン10.50.2806.0）でこのクエリが高速になるのはなぜですか

それから

？

属性を持つ2番目のステートメントTOPは6倍高速です。

内部サブクエリのcount(*)は9280行です。

HINTを使用して、SQL Serverオプティマイザーが正しく機能することを宣言できますか？

SQL Developer 3.1.07 を使用しています。インライン ヒントを含む Oracle へのクエリを実行し--+ hintましたが、SQL Developer はヒントをデータベースに送信する前に削除したようです。複数行のヒント/*+ hint */が取り除かれませんでした。SQL Developerでインラインヒント/コメントを保持するオプションはありますか?