Mysql：テーブルを定義する際に適切なデータサイズを選択して最適なデータ長を選択する理由

Question

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

これをSMALLINTに変更すると、パフォーマンスやストレージの面で賛成できなくなるでしょう...？どのようにそれを行うか説明してください。 INTとしてIDと

iは（10）INTとしてIDを有する2つの小さなテーブル
を作成
別の（100）

Iは、それぞれに513行を挿入します。私はそれらのそれぞれの表を作成する表を見るとき、私はデータサイズまたはインデックスサイズの変更を見ませんでした。彼らはMYISAMのテーブルです。それは量が減少するので、その後ここでより良いint型よりもSMALLINTを選択する際のもの（100）またはINT（10）

いただきましたが、フィールドのサイズで、より具体的にはその情報

| 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 

Answer 1

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

int（10）とint（100）は実際には同じデータ型なので、両方とも4バイトを占めます。 「10」と「100」は、データの表示方法にのみ影響し、保存方法には影響しません。

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

はmanualから役立つチャートです：あなたは私たちがパフォーマンスやディスク容量の点で、いずれかの利益を持って文句を言わない文で

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 

Answer 2

一つの理由は単純です間違いのあなたが特定の自由を制限するほど、情報はより正確になります。そのため、多くのサイトで登録すると、国や地域のリストがドロップダウンリストに表示されます。これにより、ユーザーの選択肢が減少し、安全な方法が維持されます。サイトであなたの州を入力することを許可された場合、異なるユーザーから得られるすべての例を考えてください。たとえば、フロリダ州は次のようになります。あなたが気付いた場合

• フロリダ
• FL
• FL
• Folrida

、私は最後の例では、フロリダの間違ったつづりの間違っ。フロリダ州のユーザーに対してクエリを実行しようとすると想像してみてください。ユーザーが入力できるすべてのオプションを考慮する必要があります。彼らの自由を制限することで、フィールドの中身が分かります。