0

ユーザーの詳細を格納するテーブルがあります。私は10Kの値をほとんど持つことができません。そのIDフィールドはbigint（20）として定義されており、大きなビッグデータ範囲でも保持できます。

さて、それをSMALLINTに変更すると、パフォーマンスやストレージの面で不利になります...？誰かがそれをどのように説明するかを説明しましょう。


IDがINT（10）の小さなテーブルを2つ作成
し、IDがINT（100）のテーブルを作成します。

それぞれに513行挿入しました。それぞれのshowcreatetableを見ると、データサイズやインデックスサイズに変化は見られませんでした。それらはMYISAMテーブルです。次に、int（100）またはINT（10）よりもSMALLINTを選択する方が良いことは何ですか

これがその情報です

| id    | int(10) | NO   | PRI | NULL    | auto_increment |
| size  | int(10) | YES  |     | NULL    |                |
Data_length: 4617
Index_length: 8192


| id    | int(100) | NO   | PRI | NULL    | auto_increment |
| size  | int(10)  | YES  |     | NULL    |                |
Data_length: 4617
Index_length: 8192
4

2 に答える 2

3

ここでは、データ型と「長さ」の間に重要な違いがあります。

int（10）とint（100）は実際には同じデータ型であるため、どちらも4バイトを使用します。「10」と「100」は、データの保存方法ではなく、データの表示方法にのみ影響します。

データ型の選択は、ストレージ効率と、より広い範囲の値を格納する柔軟性との間のトレードオフです。

これがマニュアルからの役に立つチャートです：

Type    Storage     Minimum Value       Maximum Value
        (Bytes)     (Signed/Unsigned)   Signed/Unsigned)
TINYINT     1   -128    127
                0   255
SMALLINT    2   -32768  32767
                0   65535
MEDIUMINT   3   -8388608    8388607
                0   16777215
INT     4   -2147483648     2147483647
                0   4294967295
BIGINT  8   -9223372036854775808    9223372036854775807
                0   18446744073709551615
于 2012-04-18T13:40:01.590 に答える
0

フィールド サイズをより具体的にする理由の 1 つは、単純にミスの量を減らすためです。誰かの特定の自由を制限すればするほど、情報はより正確になります。そのため、多くのサイトで登録すると、国や住んでいる州のドロップダウン リストが表示されます。これにより、ユーザーが持つオプションの量が減り、安全な慣行が維持されます。サイトで州を入力できる場合は、さまざまなユーザーから得られるすべての例を考えてみてください。たとえば、フロリダは次のようになります。

  • フロリダ
  • フロリダ州
  • フロリダ
  • フォリーダ

お気づきの方もいらっしゃると思いますが、最後の例でフロリダのスペルを間違えています。ここで、フロリダのユーザーに対してクエリを実行しようとした場合、どのユーザーを選択しますか? ユーザーが入力できるすべてのオプションを考慮する必要があります。彼らの自由を制限して、フィールドの中に何があるかを知ることが最善の方法です.

于 2012-04-18T13:34:17.957 に答える