ストアドプロシージャの一時テーブルのvarchar(255)
すべてのvarchar
フィールドに使用することについて、妻の仕事について議論があります。基本的に、一方のキャンプは定義が変更されても常に機能するため255を使用し、もう一方のキャンプは潜在的なパフォーマンス向上のためにソーステーブルのサイズを維持したいと考えています。
パフォーマンスキャンプは正しいですか?他に影響はありますか?彼らはSQL Serverを使用しています。
MAX()
ミックスにもいくつかあると思います。
ストアドプロシージャの一時テーブルのvarchar(255)
すべてのvarchar
フィールドに使用することについて、妻の仕事について議論があります。基本的に、一方のキャンプは定義が変更されても常に機能するため255を使用し、もう一方のキャンプは潜在的なパフォーマンス向上のためにソーステーブルのサイズを維持したいと考えています。
パフォーマンスキャンプは正しいですか?他に影響はありますか?彼らはSQL Serverを使用しています。
MAX()
ミックスにもいくつかあると思います。
回答:
一時テーブルの使用方法によっては、データの切り捨ての問題が発生する可能性があります。
この例は少し工夫されていますが、私のポイントを示しています。例:
一時テーブルは、長さ59の新しいvarchar値を喜んで受け入れます。しかし、ユーザーテーブルは受け入れられませんでした。プロシージャでこれを処理する方法によっては、切り捨てまたはエラーが発生する可能性があります。
これらの問題を文書化して説明しない限り、手順は予期しない方法で実行される可能性があります。
個人的には、この質問に対する答えが100%正しいとは思いません。一時テーブルをどのように使用しているかに大きく依存します。
お役に立てれば
ストアドプロシージャの一時テーブルの
varchar(255)
すべてのvarchar
フィールドに使用します。
私は実際のフィールド長の使用に傾くでしょう。
私は最近、MySQL(SQL Serverも同様だと思います)の一時テーブルが各varchar
列に可能な最大長を格納するのに十分なメモリを割り当てることを読みました... varchar
すべてのフィールドに必要なメモリの200%から500%を割り当てる体系的なアプローチストアドプロシージャは、システムリソースを不必要に使用しているように見えます。これらの一時テーブルを作成するために大量のメモリを使用している場合、キャッシュに使用されているメモリを不必要に要求し、ストアプロシージャが実行された後でも、将来のある時点でサーバーにより多くの作業を作成する可能性があります。
編集:ビル・カーウィンの答えを参照してください:https://stackoverflow.com/questions/1962310/importance-of-varchar-length-in-mysql-table