web-dev-qa-db-ja.com

長い列はパフォーマンスとディスク使用量にどのように影響しますか？

現在のプロジェクトでは、列を2、3文字拡張する必要があることが頻繁に発生しています。 varchar(20)からvarchar(30)などへ。

実際には、どれほど重要なのでしょうか。これはどの程度最適化されていますか？通常の「入力」フィールドに100文字、200文字、または500文字を許可することの影響は何ですか？メールに含めることができるのは320文字だけなので、OK-十分な制限があります。しかし、200に設定すると、それより長い電子メールアドレスは期待できないため、何が得られますか。

通常、テーブルには100.000行を超えることはなく、最大20または30の列があります。

現在はSQL Server 2008を使用していますが、さまざまなDBがこの問題をどのように処理するかを知ることは興味深いでしょう。

影響が非常に小さい場合-私が予想するように、この長いフィールドのパラノイアは本当に必要ではないことをDBAに納得させるために、いくつかの良い議論（リンクでバックアップされていますか？）を得るのに役立ちます。

もしそうなら、私はここに学びます:-)

sql-server-2008database-designdatatypes
27
Lars Corneliussen

あなたの質問に対する具体的な答え（少なくとも Oracleの場合 およびおそらく他のデータベース）は、フィールドの長さは問題ではなく、データの長さだけであるということです。ただし、これをフィールドを最大許容長に設定するかどうかを決定する要素として使用しないでください。以下に、フィールドサイズを最大にする前に検討する必要のあるその他の問題をいくつか示します。

Formattingフィールドのサイズに基づいてデータをフォーマットするクライアントツールでは、フォーマットに関する特別な考慮事項が必要になります。たとえば、OracleのSQL * Plusは、デフォルトでは、データが1文字しかない場合でもVarchar2列の最大サイズを表示します。比較…

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

Bad Dataフィールド長は、不良データをキャッチ/防止するための追加のメカニズムを提供します。インターフェースは、100文字のフィールドに3000文字を挿入しようとするべきではありませんが、そのフィールドが4000文字として定義されている場合は、そうする可能性があります。エラーはデータ入力段階では捕捉されませんが、別のアプリケーションがデータを処理してチョークを処理しようとすると、システムでさらに問題が発生する可能性があります。例として、後でOracleのフィールドにインデックスを付けることを決定した場合、キーの最大長を超えます（ブロックサイズと連結によって異なります）。見る…

create index i1 on f1(a);

Memoryクライアントアプリケーションが最大サイズを使用してメモリを割り当てる場合、アプリケーションは必要以上に多くのメモリを割り当てます。これを回避するには、特別な配慮が必要です。

Documentationフィールドのサイズは、データに関するドキュメントの別のデータポイントを提供します。すべてのテーブルをt1、t2、t3など、すべてのフィールドをf1、f2、f3などと呼ぶことができますが、意味のある名前を指定することで、データをよりよく理解できます。たとえば、米国に顧客がいる会社の住所テーブルに、2文字のStateというフィールドがある場合、2文字の州の省略形を入力する必要があります。一方、フィールドが100文字の場合、完全な州名がフィールドに入力されると予想されます。

とはいえ、変化に備えることは賢明に思えます。今日のすべての製品名が20文字で収まるからといって、常にそうであるとは限りません。行き過ぎて1000にしないでください。ただし、もっともらしい拡張の余​​地を残してください。

12
Leigh Riffel

ここからが出発点になります。

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

元の質問を誤解したかもしれません。参照用に他のリンクをいくつか見つけられるかどうか確認してみましょう。

以下は、データ型の選択に関する適切なリファレンスです。 http://sqlfool.com/2009/05/performance-considerations-of-data-types/

Varchar（20）からvarchar（30）への変更は小さなことのように思えるかもしれませんが、潜在的な問題を認識するために、データベース構造がどのように機能するかについてさらに理解する必要があります。たとえば、varchar（30）に移動すると、1ページ（8060バイト未満）に格納できる列の転換点（すべての30バイトが使用される場合）を超えてプッシュできます。これにより、使用されるディスク領域が増加し、パフォーマンスが低下し、トランザクションログのオーバーヘッドがさらに増加し​​ます。

データベース構造のリンクは次のとおりです。 http://technet.Microsoft.com/en-us/sqlserver/gg313756.aspx

以下は、ページ分割とtrxロギングの1つです。 http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx

HTH

9
SQLRockstar

スタックオーバーフローの質問 で見つけた別の興味深い点を共有したいと思いました。

元の回答：Nick Kavadias

最大またはテキストフィールドを使用しない理由は、SQL Server Enterprise Editionでも オンラインインデックスの再構築 、つまりREBUILD WITH ONLINE = ONを実行できないためです。

N/varchar（max）列を任意に追加する場合、これは大きな欠点であると私は考えます。MSサイトによると、オンラインインデックスの再構築に対するこの制限はSQL Server 2008、2008 R2およびDenaliに残っています。したがって、SQL Server 2005に固有のものではありません。

7
Jeff

場合によっては、varcharフィールドに割り当てるスペースの量が、メモリ内の並べ替えに割り当てられるメモリの量に影響します。

SQLWorkshops.comでのプレゼンテーションは刺激的だと思いました。このプレゼンテーションでは、char/varcharフィールドに十分なメモリが割り当てられていないために、order byの並べ替えがtempdbに波及しているケースについて説明しています。

http://webcasts2.sqlworkshops.com/webcasts.asp

このWebキャストは、次のWebサイトにも記事として掲載されました。

http://www.mssqltips.com/tip.asp?tip=1955

このプレゼンテーションでは、並べ替えの対象となる列はchar/varchar列ではありませんが、メモリ内のvarchar列に割り当てられた領域の量によって、クエリのパフォーマンスが異なる場合があることに注意してください。

6
Jeff

ANSI_PADDINGをONに設定しますか？

末尾に空白がたくさんあります...

4
gbn

これは、ディスク容量と文字長にのみ関係します。もちろん、charデータ型とこれらのデータ型のインデックスの検索は、整数よりも遅く動作しますが、これは別の議論です。

Varcharデータ型は「可変」データ型であるため、varchar（500）の制限を設定した場合、これはそのフィールドの最大文字長です。最小長は0〜500です。一方、要求されるディスク領域は、10、30、または500文字のフィールドでは異なります。

データ型varchar（800）とnull値のテストをときどき行い、17バイトを使用しました。挿入された各文字に1バイト追加しました。たとえば、400文字の文字列では、ディスクで417バイトが使用されていました。

2
yrushka

実際の最大長が20以下である限り、varchar（20）またはvarchar（（8000））の列で作成されたテーブル間に違いはないと思います。

一方、より長い文字列を格納する可能性をユーザーに提供することで、ユーザーがそれを実行するように促す場合があります。

2
bernd_k