一時テーブルでvarcharサイズは重要ですか?


16

ストアドプロシージャの一時テーブルのvarchar(255)すべてのvarcharフィールドに使用することについて、妻の仕事について議論があります。基本的に、一方のキャンプは定義が変更されても常に機能するため255を使用し、もう一方のキャンプは潜在的なパフォーマンス向上のためにソーステーブルのサイズを維持したいと考えています。

パフォーマンスキャンプは正しいですか?他に影響はありますか?彼らはSQL Serverを使用しています。


多分、そもそも一時テーブルは必要ないと思う。それらは何のために使用されていますか?必要な場合、これらの特定の列は何に使用されますか?結合またはあらゆる種類の比較に使用されていますか?基になる列はnvarcharであり、varcharではありませんか?
アーロンバートランド

@AaronBertrand一時テーブルはモジュール化のためにあります。データは、変更される可能性のあるビジネスルールに基づいて、何度も変換および入力されます。MAX()ミックスにもいくつかあると思います。
ブライアンニッケル

回答:


6

一時テーブルの使用方法によっては、データの切り捨ての問題が発生する可能性があります。

この例は少し工夫されていますが、私のポイントを示しています。例:

  1. ユーザーテーブルの列はvarchar(50)です。
  2. 一時テーブルの列はvarchar(255)です。
  3. ユーザーテーブルのその列に45文字のレコードがあります。
  4. 手順では、一時テーブルをユーザーテーブルにマージする前に、「-for the win」をその列の最後に連結します。

一時テーブルは、長さ59の新しいvarchar値を喜んで受け入れます。しかし、ユーザーテーブルは受け入れられませんでした。プロシージャでこれを処理する方法によっては、切り捨てまたはエラーが発生する可能性があります。

これらの問題を文書化して説明しない限り、手順は予期しない方法で実行される可能性があります。

個人的には、この質問に対する答えが100%正しいとは思いません。一時テーブルをどのように使用しているかに大きく依存します。

お役に立てれば


0

ストアドプロシージャの一時テーブルのvarchar(255)すべてのvarcharフィールドに使用します。

私は実際のフィールド長の使用に傾くでしょう。

私は最近、MySQL(SQL Serverも同様だと思います)の一時テーブルが各varchar列に可能な最大長を格納するのに十分なメモリを割り当てることを読みました... varcharすべてのフィールドに必要なメモリの200%から500%を割り当てる体系的なアプローチストアドプロシージャは、システムリソースを不必要に使用しているように見えます。これらの一時テーブルを作成するために大量のメモリを使用している場合、キャッシュに使用されているメモリを不必要に要求し、ストアプロシージャが実行された後でも、将来のある時点でサーバーにより多くの作業を作成する可能性があります。

編集:ビル・カーウィンの答えを参照してください:https//stackoverflow.com/questions/1962310/importance-of-varchar-length-in-mysql-table


2
SQL Serverが似ていると仮定しますか?私は...ないだろう
AK

申し訳ありませんが、私の答えは不完全です。私が意味するのは、その仮定が間違っていると立証されない限り、私は警告の側で過ちを犯すことです(すなわち、パフォーマンスに悪影響を与える可能性のある変更を加えないことです)。
マット
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.