MySQLストレージフィールドタイプのクエリ効率についての簡単な理解

検索パフォーマンスは最速から最遅まで次のとおりです (私が聞いたところによると)。

1 番目: tinyint、smallint、mediumint、int、bigint
2番目: char、varchar
3番目: NULL

説明（再録）：

整数型

1. TINYINT、SMALLINT、MEDIUMINT、INT、BIGINTはそれぞれ8、16、24、32、64バイトを使用します。

2. 整数にはすべてオプション属性 UNSIGNED があります (たとえば、tinyint フィールドの値の範囲は unsigned の場合 0 ～ 255 ですが、signed の場合の範囲は -128 ～ 127 です。したがって、負の値が必要ないことが明らかな場合は、通常、負の数をサポートするために signed を設定しません)。

3. INT(1)とINT(20)は保存と計算において同じです。INT(N)のNは、一部の対話型ツールによって表示される文字数のみを指定します。

文字タイプ

charは固定長で、ストレージ効率はvarcharほど良くありませんが、短いデータのクエリにはvarcharよりも劣ります。

固定長。たとえば、uuid が主キーとして使用されている場合は、char の方が適切です。

NULL型

1. NULL列のインデックスには余分なスペースが必要

2. 比較と計算中にNULL値が処理され、インデックスの失敗を引き起こす可能性があります。

したがって、NULL型の使用は避け、整数型を使用するようにしてください。

さらに、時間日付データ型

1. 日付データを保存するのにスペースを無駄にする文字列を使用しないでください。

2. DATE は、1001 年から 9999 年までの年を秒単位の精度で保存できます。日付と時刻を 8 バイトを使用して YYYYMMDDHHMMSS 形式の整数にカプセル化します。

3. TIMESTAMP は、Unix タイムスタンプと同じ、1970 年からの秒数を格納します。1970 年から 2038 年までしか格納できず、4 バイトを使用します。

4. 2つの関数FROM_UNIXTIME()とUNIX_TIMESTAMP()は日付とUnixタイムスタンプを変換します。

5. DATE と TIMESTAMP は時間を保存しますが、時間はどこにありますか? ? ?前者はどこにいても（タイムゾーンに関係なく）時間を表すもので、後者はグリニッジ標準時です。。つまり、保存時に、与えられた時間に応じて DATE を保存し、保存前にタイムゾーンと与えられたタイムスタンプに基づいて、対応するグリニッジ標準時に応じて TIMESTAMP を最初に計算します。アクセスすると、保存された時間に応じて DATE が返され、保存されたタイムスタンプ (グリニッジ標準時とみなされます) とタイムゾーンに応じて TIMESTAMP が計算され、タイムゾーン内の対応する時間が計算されます。

6. 通常はTIMESTAMPが使用され、スペース効率が高い

7. MYSQL は、秒未満の粒度の日付と時刻の値を提供しません。必要に応じて、BIGINT を使用してマイクロ秒レベルのタイムスタンプを保存するか、DOUBLE を使用して秒後の小数部分を保存できます。

実数型

1. DECIMALは財務目的で使用される

2. DECIMALはBIGINTの範囲外の整数を保存できる

3. FLOATとDOUBLEは、近似計算に標準的な浮動小数点演算を使用します。

char と varchar

1. char は固定長、varchar は可変長です。つまり、varchar はスペースを節約します (ROW-FORMAT=FIXED を使用して作成しない限り)

2. varcharは可変長なので、UPDATE中に長さが長くなると、追加の作業が行われます。

3. 文字列列の最大長が平均長よりもはるかに大きい場合、列がめったに更新されない場合（断片化が問題にならない場合）、UTF8 などの文字セットが使用されている場合（各文字が異なるバイト数を使用して格納される場合）には、varchar を使用します。

4. CHARは次のような場合に適しています: 非常に短い、またはすべての値が同じ長さに近い場合(MD5など)、列が頻繁に変更される場合

5. 末尾のスペースの問題: 上位バージョンの varchar では末尾のスペースが保持されますが、char および下位バージョンの varchar では末尾のスペースが削除されます。