(別の長さではなく)VARCHAR(255)が頻繁に使用されるのを確認する理由はありますか?


158

複数のコース、本、および仕事で、VARCHAR(255)として定義されたテキストフィールドを「短い」テキストのデフォルトの一種として見ました。良い丸めの数字である以外に 255の長さが頻繁に選択される理由はありますか?正当な理由があった過去のある時点からのホールドアウトですか(それが今日適用されるかどうかにかかわらず)?

もちろん、ストリングの最大長がどういうわけかわかっている場合は、より厳しい制限がより理想的であることを理解しています。ただし、VARCHAR(255)を使用している場合は、おそらく最大長がわからないことを示していますが、それは「短い」文字列であることだけを示しています。


注:私はこの質問を見つけました(VARCHAR(255)V TINYBLOB V TINYTEXT)、VARCHAR(と言っていたnが)必要とn個の保存の1バイトのn <= 255、n個のストレージの2つのバイトをn個 255>。これが唯一の理由ですか?VARCHAR(256)と比較して2バイトしか節約できず、VARCHAR(253)と宣言することで、簡単に別の2バイトを節約できるため、それは一種の恣意的なようです。

回答:


109

歴史的に、VARCHAR一部のDBMS では255文字がaの最大長であることが多く、UTF-8を使用して列にインデックスを付けたい場合(インデックスの長さに制限があるため)、有効な最大長になることがあります。


4
@CharlesBretana:引用した残りの文を読むと、要求している正確な説明が見つかります。
2016

2
@CharlesBretana:「偽のUTF-8」とは、MySQLの「utf8」エンコーディングを意味します。これは、前述のように、文字ごとに3バイトを予約します(制限されています)。これはUTF-8の非常に良いバージョンではありません。MySQLで適切なUTF-8が必要な場合は、その「utf8mb4」エンコーディングを使用する必要があります。しかし、人々はそれを知らないで "utf8"を使う可能性がはるかに高く、UTF-8を他のどのエンコーディングよりも必要とする可能性がはるかに高いため、VARCHARのインデックス可能な最大長は255文字です。それにもかかわらずあなたの驚き。
混沌

3
@CharlesBretana:私はこれを3回説明しましたが、変わったことは1つもありません。MySQLのインデックスの長さの制限は依然として767バイトであり、3バイトのUTF-8文字をエンコードするために必要なバイト数は依然として3であり、floor(767/3)は依然として255です。 。
混乱

1
@CharlesBretana(このパーティー全体に遅れて申し訳ありません)私はDBスペシャリストではありませんが、混乱が何を言っていると思います:はい、「偽のUTF-8」列は255文字を超えることができますが、インデックスはvarcharの最初の255文字のみを処理し、完全にインデックスを作成する場合は、事実上列の最大値にします。これが彼の説明について私が理解したことだけです、私は間違っているかもしれません、私はSQLインデックスの専門家ではありません。
Francis Lord

2
@CharlesBretanaカオスの答えを適切に見ると、2つの部分に分かれていることがわかります。1。Varchar(255)の背後にある歴史的な理由があまりにも一般的であること(以前の一部のDBMSでは最大であった)、2。前述のインデックスの制限のため、現在でも一部の制限です。パート1とパート2はリンクされていません。パート1は質問に対する実際の回答であり、パート2はサイドノートであり、今日でもそれが依然として制限である理由を説明しているため、依然として質問に関連しています。(続き->)
フランシス卿

161

255が使用されるのは、8ビットの数値でカウントできる最大の文字数だからです。255を超える文字をカウントするために別のバイト全体を軽々と必要とせずに、8ビットカウントの使用を最大化します。

この方法で使用すると、VarCharはバイト数+ 1のみを使用してテキストを格納するため、フィールドの文字数にハード制限(50など)が必要でない限り、255に設定することもできます。


90
私はそのフレーズが好きです:「別のバイト全体を軽々と要求する」。=)
MusiGenesis 2009

7
これは、varcharがUTF-8であるDBにも当てはまりますか?
antak

1
@antak:MySQLでは、InnoDBを使用するため、キー列は767バイトを超えることはできません。VARCHAR列がUTF8の場合(各文字が最大3バイトを使用する可能性があることを意味します)、列の最大許容長はfloor(767/3)= 255です。まさにその理由で「767」が選択されたと想定しています。
BlueRaja-Danny Pflughoeft 2016年

1
文字セットである場合はutf8varchar(85)限界である交差点がチップ上に長さバイト 1〜2バイトからです。もしそうならutf8mb4、それはvarchar(63)です。これらは、オンラインのALTER TABLEを使用しVARCHARの長さを拡張できる最大であるため、重要です。結果として、varchar(2) charset utf8列を持つテーブルを作成し、与えられた範囲をどれだけ拡張できるかを確認することで、これらの数値を導き出しましたALGORITHM=INPLACE
antak 2017

Back In The Dayの多くの「データベース」が磁気テープに保存されていたと考えると、それはさらに意味があります。2の倍数のサイズの「ブロック」でデータを読み取ることは非常に一般的でした。このようにして、データが最も効率的に保存されました(古いメインフレームで実行している場合、そのような小さな効率はmake-it-or-break-it最適化でした)。
TMN

23

おそらく、SQL ServerとSybase(よく知っている2つを挙げると)の両方で、VARCHAR列の文字数は最大255文字でした。SQL Serverの場合、これは1996/1997年のバージョン7で変更されました...しかし、古い習慣はときどき死にます。


8
特定のDBとバージョンを引用する場合は+1。そして、「古い習慣は一生懸命に死ぬ」というのが、おそらく最も正しい答えです。
Andrew M

17

:私は、文字通りの質問に答えるつもりです いいえ、あなたはVARCHAR(255)(確かにありますので、頻繁に使用される参照の正当な理由がない理由は他の答え、ちょうど良いではないもので説明したように、)。アーキテクトがVARCHAR(255)ではなくVARCHAR(300)を選択したため、致命的に失敗したプロジェクトの例は多くありません。VARCHARではなくCHARについて話していても、これはほとんど意味がない問題です。


255バイトのうち1バイトは0.4%です。時々、あなたは最後の半パーセントかそこらを気にかけます。時々そうしない。あなたがホスティングとパフォーマンスのコストが数十ドルに達した場合、あなたはおそらく気にしません。彼らが数百万人に遭遇した場合、おそらくそうです。
エドワードブレイ

2
@EdwardBrey:ムーアの法則が依然として真実である場合、ここでの私の答えは、私が書いたときの16倍有効です。
MusiGenesis 2017年

コンピューターが私たちを助けることができる方法が16倍以上発見されない限り。速度はまだ機能です。
Edward Brey 2017年

14

あなた2^8が得ると言うとき256、しかしコンピュータ用語での数は数から始まります0。したがって、を取得し255たら、IPのインターネットマスクまたはIP自体でプローブできます。

255 は、8ビット整数の最大値です。 11111111 = 255

それは役に立ちますか?


1
整数の場合、0から始まり、255で終わります。ただし、文字列の場所では、1位から数えます。256ではなく、1から始めたので意味がありません。 0?string_length()の結果が原因で、私はvarchar(256)に完全に同意していませんが、実際には確実ではありません。
HoldOffHunger 2016年

1
データベースの@HoldOffHunger文字列の長さはゼロ文字にすることができるため、長さが8ビットで格納される場合の許容される長さの範囲は0〜255です。すべての文字列に少なくとも1文字が必要であると言いたい場合は、 8ビット長の256文字の文字列をサポートできます。
phoog

7

注:私はこの質問を見つけました(VARCHAR(255)V TINYBLOB V TINYTEXT)、VARCHAR(と言っていたnが)必要とn個の保存の1バイトのn <= 255、n個のストレージの2つのバイトをn個 255>。これが唯一の理由ですか?VARCHAR(256)と比較して2バイトしか節約できず、VARCHAR(253)と宣言することで、簡単に別の2バイトを節約できるため、それは一種の恣意的なようです。

いいえ。253を宣言しても2バイトは節約できません。varcharの実装は、おそらく長さカウンターであり、可変長で終了していない配列です。これは、 "hello"をvarchar(255)に格納する場合、6バイトを占有することを意味します。長さ(数値5)に1バイト、5文字に5バイト。


3
このステートメントは、すべてのデータベースに当てはまるわけではありません。多くのデータベースは、テーブルで指定されたサイズのvarcharフィールドを使用するため、そのフィールドが行に対して変更されたときに行を移動する必要はありません。
SingleNegationElimination 2009

はい、あなたは正しいです。実装に依存します。あなたはベンダーマニュアルをチェックして何が起こっているのかを確認する必要があります
Stefano Borini

2
許容されるかもしれませんが、VARCHARそのように実装すると、の代わりにを使用するという全体のポイントが無効VARCHARになりCHARます。
dan04

4

符号なし1バイトの数値には、範囲[0-255]を含めることができます。255が表示された場合、それは主にプログラマーがベースで考えているため10です(ジョークを取得しますか?):)

実際、しばらくの間、MySQLでVARCHARを指定できる最大サイズは255でしたが、インデックス作成やその他の問題でTEXTよりもVARCHARを使用する方が有利です。


4

MsOffice(バージョン2000または2002まで)などの多くのアプリケーションでは、セルあたりの最大文字数は255でした。フィールドあたり255文字を超える処理が可能なプログラムから、これらのアプリケーションとの間でデータを移動することは悪夢でした。現在、制限はますます少なくなっています。


2

0000 0000- >これは8ビットの2進数です。数字はビットを表します。

あなたはそのように数えます:

0000 0000 →(0)

0000 0001 →(1)

0000 0010 →(2)

0000 0011 →(3)

各ビットは、オンまたはオフの2つの値のいずれかです。合計の最大数は、乗算で表すことができます。

2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 - 1 = 255

または

2^8 - 1. 

最初の数が0であるため、1を減算します。

255はかなりの値(しゃれが意図されていない)を保持できます。

より多くのビットを使用すると、最大値は指数関数的に増加します。したがって、多くの目的で、ビットを追加するのはやり過ぎです。


1

別の理由としては、RDOやADO(COMバージョンはADO.NETではない)などのWindowsの非常に古いデータアクセスライブラリでは、255文字を超える列からデータを取得するために特別なメソッドGetChunkを呼び出す必要があったことが考えられます。varchar列を255に制限した場合、この追加のコードは不要でした。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.