3

継承したいくつかの T-SQL (SQL Server 2008) があり、一部のクエリの実行が非常に遅い理由を見つけようとしています。には、Actual Execution Plan19%、21%、26% のコストがかかる 3 つのクラスター化インデックス スキャンがあるため、これが問題の原因のようです。

通常、フィールドの内容は数値です (ただし、一部のジョブ番号にはアルファベットのプレフィックスが付いています)。

データベースの設計 (ベンダー提供) はかなり貧弱です。アプリケーションでのジョブ番号の最大長は 12 文字ですが、結合されたテーブルではvarchar(50)、いくつかの場所とvarchar(15)他の場所で定義されています。私のパラメータは ですが、varchar(12)に変更すると同じことが得られますvarchar(50)

ノードには次のものが含まれます。

Predicate: [Live_Costing].[dbo].[TSTrans].[JobNo] as [sts1].[JobNo]=CONVERT_IMPLICIT(varchar(50),[@JobNo],0)

sts1は派生テーブルですが、プル元のテーブルjobnoはvarchar(50)

2 つの varchar 間で暗黙的な変換を行う理由がわかりません。長さが違うだけなのでしょうか？

私は実行計画にかなり慣れていません

実行計画のどのノードがクエリのどの部分に関連しているかを簡単に把握する方法はありますか? 述語、結合節ですか?

よろしく

マーク

4

1 に答える 1

1

一部の変数は照合を行うことができます：ここにリンクの説明を入力してください

サーバー、DB、テーブル、および列レベルで指定できる照合を検証する必要があります。

まず、tempdbとベンダー提供のデータベース間の照合を確認します。一致するはずです。そうでない場合は、暗黙的な変換を行う傾向があります。

ベンダー提供のコードベースを変更できない場合は、次の1つ以上が役立ちます。1）一時テーブルを事前定義し、tempdbではなく使用中のdbと同じ照合をキーフィールドに指定します。2）文字列比較を行うときに照合を提供します。3）一時テーブルで「selectinto」を使用する場合は、キー値の照合を指定します。4）テーブルと列の照合がデータベースの照合と一致することを確認します（ベンダーから既存のデータベースに特定のテーブルのみをインポートした場合は非常に重要です）。

ベンダー提供のコードベースを変更できる場合は、varcharではなくすべてのcharキーを同じ長さにするためのコストを確認することをお勧めします。Varcharのオーバーヘッドは10です。注意点は、nullではない固定長の文字フィールドを作成すると、右側にパディングされることです（避けられません）。

理想的には、intキーがあり、ユーザーインタラクション/ルックアップにvarcharフィールドのみを使用します。

テーブルProductsを作成します（ProductID int not null Identity（1,1）primary key clustered、ProductNumber varchar（50）not null）

テーブルの変更製品制約の追加uckProducts_ProductNumberunique（ProductNumber）

次に、ProductNumberではなくProductIDですべての結合を実行します。ProductNumberでフィルタリングするだけです。

完全に大丈夫でしょう。

于 2013-01-16T04:18:22.217 に答える