0

以前の投稿で述べたように、私は SQL Server フレームワークに基づくウェアハウスを継承しました。

既存のコンポーネントと前任者によって採用されたプラクティスを継続的に見直していると、注意を引き、驚いたことがわかりました。大量のデータを操作するためのテンポラル テーブルとして物理テーブルが使用されている場所がいくつかあります。最初の反応は、この方法は DBMS にとって非常にコストがかかるということでしたが、それについてもっとフィードバックが欲しいというものでした。

このトピックに関するいくつかの注釈:

  • SP内で作成/削除される物理テーブル(「TMP_TableName」と呼ばれるテーブル)
  • 大量のデータを操作するために主に使用されるテーブル
  • 言及されたSPは、毎日の夜間処理中に数回電話をかけました

質問:

  1. このプラクティスは、私が認識していない処理ルーチンに何らかの利点をもたらしますか?
  2. これに関するベストプラクティスはありますか?
  3. 私の計画は、パフォーマンスを改善するために #temp テーブルを使用するようにコードを更新することです。それについてのコメント?.
  4. 変数テーブルの使用を検討する必要がありますか? ビッグデータを扱うとパフォーマンスが悪いと読みました。

すべてのstackoverflowersと共有したい知識/経験に基づくフィードバックをお待ちしております。

前もって感謝します、

4

2 に答える 2

0
  1. このプラクティスは、私が認識していない処理ルーチンに何らかの利点をもたらしますか?

特定のデータをテーブルにダンプしたり、特定のインデックスを作成したりすることで、パフォーマンスを向上させることができます。つまり、同じ大規模で限られたデータセットを複数回使用する場合や、インデックスを必要とする計算列がある場合です。多くの場合、これはキャッシング/スプーリングなどを通じて、SQL によって舞台裏で発生します。

  1. これに関するベストプラクティスはありますか?

個人的には、後でデバッグできるように、テーブルをそのまま残します。それを行う場合は、実行ごとに事前にテーブルをクリアするコードが必要になります

現在のアプローチには重大な欠点があります。2 つのプロセスがストアド プロシージャを同時に実行すると、データが「衝突」します。

私の計画は、パフォーマンスを改善するために #temp テーブルを使用するようにコードを更新することです。それについてのコメント?.

DB が低速ディスク上にあり、tempdb が高速ディスク上にあり、RAM が不足しているため常にディスクを使用しなければならない場合を除き、パフォーマンスが変化する可能性はほとんどありません。

ただし、これにより、SP が複数のプロセスで同時に実行されるという問題が修正されます。

変数テーブルの使用を検討する必要がありますか? ビッグデータを扱うとパフォーマンスが悪いと読んだ

基本的にいいえ.....前の投稿で完全にカバーされています。

要約すると、プロセスをデバッグする必要がない限り、一時 (#) テーブルに変換します

于 2014-12-18T00:55:59.950 に答える
0

一時テーブル (#temp) は、データベースで作成する他のテーブルと同じユーザー テーブルですが、重要な違いが 1 つあります。インスタンス化されると、tempdb 内で一意の名前が付けられます。このように、複数の接続が同じプロシージャを呼び出す場合、それらは互いの一時テーブルを踏むことはありません。

一時テーブルのベスト プラクティスは、通常、#temp を使用することです。頭に浮かぶ簡単な例外の 1 つは、一度に 1 つのプロセスでしか使用されないことがわかっている永続的なステージング テーブルです。

#temp テーブルに切り替えるか、永続的なステージング テーブルとして作成します。

通常、テーブル変数は使用しません。これらは引き続き一時テーブルであり、tempdb に格納されますが、作成後にインデックスを作成して操作する方法は非常に限られています。そうは言っても、それらは少量のかなり静的なデータに役立ちます。どちらか一方しか使用できない操作がいくつかあります。

一時テーブルとテーブル変数の違いの詳細については、こちらを参照してください。完全な説明については、こちらを参照してください

それが役立つことを願っています!

粘土

于 2014-12-18T00:11:37.717 に答える