web-dev-qa-db-ja.com

varchar列の長さ-255を使用する利点はありますか？

私はしばしばvarchar(255)の列に出くわすので、これはおそらくソートの規則です。 255は2 ^ 8-1です。つまり、2 ^ n-1の長さについて「魔法の」何かがありますか？または具体的には255ですか？特定のvarchar長さにパフォーマンスまたはストレージ最適化の利点はありますか？または、これは現在のバージョンのMariaDBとMySQLには適用されなくなった古い知恵でしょうか？

mysqlmariadb
5
dbdemon

私はたまに255に反対しています。確かにあります以前は使用されていました '255'のいくつかの理由。

MySQLでは、191、255、767、64K、およびおそらく他の値で停止する理由があります。エンジンに依存するもの、_CHARACTER SET_に依存するものなどがあります。

VARCHARは、1バイトまたは2バイトの長さと、現在のテキストに十分なバイト数として、指定した文字セットで格納されます。ただし、1または2の選択はnotは個々の列によってのみ駆動されます。行の合計サイズによって決まります。つまり、これは255を使用するための有効な言い訳にはなりません。

ある長さを使用してください

  • 保守的に超えられないほど十分に大きいが、
  • 合理的に見えるほど小さい。

私が怒っている間... CHAR（fixed length）はめったに勧められません。そして、ほとんどの場合、それは_CHARACTER SET ascii_である必要があります-country_code、postal_code、Y/N、M/F、MD5、UUID、base64など（MD5とUUIDはさらに一歩踏み出す必要がありますが、それは別の怒りです。 ）

「255」を盲目的に使用することによる潜在的な悪影響：

  • lotの列がある場合、最大行サイズ制限に達する可能性があり、_CREATE TABLE_は失敗します。
  • インデックスサイズの制限をオーバーフローする可能性があります。
  • 複雑なSELECTsには一時テーブルが必要な場合があり、MEMORYを使用できます。この場合、VARCHAR(255)は一時テーブルのCHAR(255)になります。そして、utf8を使用する場合、それはすべての行で755バイトです。 （8.0はこの設計上の欠陥を修正しますか？）

関連：すべての数字に盲目的にBIGINTを使用しないでください。 8バイトかかります。 INTでさえ、4バイトでは過剰です。 MEDIUMINT、SMALLINT、およびTINYINTを参照してください。 INT(2)の_(2)_は何も意味しないことに注意してください。それでも4バイトかかります。

6
Rick James

ある時点では、それはSybaseおよび派生SQL Serverの列の最大長でした。他の人が互換性を維持するためにコピーしたので、アプリケーション/ SQLを新しいプラットフォームに移行するのは難しくありませんでした。

互換性以外に、それを永続化する正当な理由はありません。最近、varchar（max）に置き換えられているようです。

3
Mike

「標準」の列の長さは至る所で使用されており、列の実際に必要な長さを理解するために実行された努力がないことを常に示しています。

24文字を超えない列がある場合、列の長さを255に指定するのはなぜですか？

可変長の列の正しい長さを分析して使用すると、わずかな労力で済みます。また、長すぎる列の長さを使用した場合の副作用が問題になることはありません。 MySQLについての質問ですが、 この答え は、SQL Serverが列の長さをさまざまな方法で使用する方法を示しています。

2
Max Vernon