3

それぞれにかなり標準的なデータを含むいくつかのテーブルがあります。このデータに最適な列の種類を教えて、誰かがそれらを最適化するのを手伝ってくれませんか? それらの横にあるのは、私が現在持っているものです。

Number (max length 7) --> MEDIUMINT(8) Unsigned
Text (max length 30) --> VARCHAR(30)
Text (max length 200) --> VARCHAR(200)
Email Address (max length 200) --> VARCHAR(200)
Number (max length 4) --> SMALLINT(5) Unsigned
Number (either 0 or 1) --> TINYINT(1) Unsigned
Text (max length 500) --> TEXT

助言がありますか？あくまでも推測なので間違っているところもあると思いますが…

4

4 に答える 4

2

これがあなたの質問に対する直接的な回答でなくて申し訳ありませんが、これは指摘する必要があると思います。列タイプの後の括弧内の整数の目的を誤解している可能性があると思います。

型についてVARCHARは、おそらくすでにご存じのとおり、最大長が制限されます。ただし、特定の文字列の格納に使用されるバイト数には影響しません。VARCHAR(100)長さ 5 の文字列は、 に保存されている場合でもに保存されている場合でも、同じバイト数のストレージが必要ですVARCHAR(200)。

整数型の場合、数値はストレージのバイト数とはまったく関係ありません。それは別のものである表示幅です。マニュアルを参照してください:

別の拡張機能が MySQL でサポートされており、オプションで整数データ型の表示幅を、型のベース キーワードに続く括弧で指定します (たとえば、INT(4))。このオプションの表示幅をアプリケーションで使用して、左にスペースを埋め込むことにより、列に指定された幅よりも狭い幅の整数値を表示できます。(つまり、この幅は結果セットで返されるメタデータに存在します。使用するかどうかはアプリケーション次第です。)

表示幅は、列に格納できる値の範囲や、列に指定された幅を超える値の表示桁数を制限しません。

于 2010-05-22T18:53:55.550 に答える
0 
Number (either 0 or 1) --> TINYINT(1) Unsigned

それはブール値でなければなりません。

于 2010-05-22T18:46:52.553 に答える
0

あなたはすでにそれをかなり賢明にしています。

列の型では何も最適化できないことに注意してください。インデックスを使用します。

于 2010-05-22T18:54:49.710 に答える
0

「効率的」の定義に依存します。速度については、CHAR は VARCHAR よりも高速です (各行が同じ長さになるため、特定のレコードを簡単にシークできます)。ただし、すべてのフィールドは固定長である必要があります。または気にしないでください。

于 2010-05-22T18:56:42.330 に答える