MySQL のデータ型についての包括的な理解

1. Char 型と varchar 型

char 型と varchar 型は似ており、どちらも 文字列 を保存するために使用されますが、文字列の保存と取得の方法が異なります。 char は固定長文字型に属し、varchar は可変長文字型に属します。例: char(4) と varchar(4) の 2 つの型定義の場合:
(1) と '' は char(4) で 4 バイトを占有しますが、varchar(4) は 1 バイトのみを占有します。
(2)、'ab' は char(4) で 4 バイトを占有しますが、varchar(4) は長さ 3 バイトのみを占有します。

(3)、'abcd' は char(4) で 4 バイト、 varchar(4);

varchar 型に余分なバイトがあるのはなぜですか?これは、varchar 型が varchar 型の実際の長さを格納するために余分なバイトを使用するためです。 char(4) と varchar(4) の取得は常に同じとは限りません。例:

mysql> create table char_and_varchar (v varchar(4),c char(4));
Query OK, 0 rows affected (0.20 sec)

mysql> insert into char_and_varchar values ('ab  ','ab  ');
Query OK, 1 row affected (0.33 sec)

mysql> select concat(v,'cd'),concat(c,'cd') from char_and_varchar;
+----------------+----------------+
| concat(v,'cd') | concat(c,'cd') |
+----------------+----------------+
| ab  cd         | abcd           |
+----------------+----------------+
1 row in set (0.35 sec)

char は固定長であるため、処理速度は varchar よりもはるかに高速ですが、欠点はストレージの無駄です。 space の場合、プログラムは末尾のスペースやその他の欠点を処理する必要があるため、長さがあまり変化せず、クエリ速度の要件が高いデータは char 型に格納されると考えられます。 MySQL のバージョンアップが進むにつれ、varchar

データ型
のパフォーマンスも向上し続け、varchar 型の適用範囲はさらに広がっていくでしょう。 MySQL では、ストレージ エンジンごとに char と varchar の使用原則が異なります:

(1) MyISAM ストレージ エンジンでは、可変長フィールド タイプの代わりに固定長フィールド タイプを使用することが推奨されます。
(2). 現在、メモリストレージエンジンには固定長のデータ行が格納されているため、char型であってもvarchar型であってもchar型に変換して処理します。
(3). InnoDB ストレージ エンジンでは、varchar 型を使用することをお勧めします。

2. TEXT と BLOB

少数の文字列を保存する場合は、char および varchar データ型を使用できます。大きなテキストを保存する場合は、通常、テキストまたは BLOB の使用を選択します。 2 つの主な違いは、BLOB は写真などのバイナリ データの保存に使用できるのに対し、テキストは文字タイプのデータの保存にのみ使用できることです。 Text と BLOB には、それぞれ text、mediumtext、longtext と blob、mediumblob、longblob の 3 つの異なるタイプが含まれます。それらの主な違いは、保存されるテキストの長さとバイト数です。

BLOB および TEXT タイプを使用するときに注意すべきいくつかの問題:

(1)、BLOB および TEXT は、特に多数の削除操作が実行される場合にパフォーマンス上の問題を引き起こします。削除操作によりデータ テーブルに大きな「穴」が残り、将来これらの「穴」レコードを埋めると、挿入のパフォーマンスに影響します。パフォーマンスを向上させるには、定期的に OPTIMIZETABLE 関数を使用してそのようなテーブルをデフラグし、パフォーマンスの問題の原因となるホールを回避する必要があります。

(2)、合成インデックスを使用して、大きなテキスト フィールドのクエリ パフォーマンスを向上させます。いわゆる合成インデックスは、大きなテキスト フィールドの内容に基づいてハッシュ値を作成し、この値を別のデータ列に格納します。その後、ハッシュ値を通じてデータ行を見つけることができます。例:

mysql> create table t (id varchar(100),content blob,hash_value varchar(40));
Query OK, 0 rows affected (0.03 sec)

mysql> insert into t values (1,repeat('beijing',2),md5(content)); 
Query OK, 1 row affected (0.33 sec)

mysql> insert into t values (2,repeat('beijing',2),md5(content)); 
Query OK, 1 row affected (0.01 sec)

mysql> insert into t values (2,repeat('beijing 2008',2),md5(content));
Query OK, 1 row affected (0.01 sec)

mysql> select * from t;
+------+--------------------------+----------------------------------+
| id   | content                  | hash_value                       |
+------+--------------------------+----------------------------------+
| 1    | beijingbeijing           | 09746eef633dbbccb7997dfd795cff17 |
| 2    | beijingbeijing           | 09746eef633dbbccb7997dfd795cff17 |
| 2    | beijing 2008beijing 2008 | 1c0ddb82cca9ed63e1cacbddd3f74082 |
+------+--------------------------+----------------------------------+
3 rows in set (0.00 sec)

mysql> select * from t where hash_value=md5(repeat('beijing 2008',2));
+------+--------------------------+----------------------------------+
| id   | content                  | hash_value                       |
+------+--------------------------+----------------------------------+
| 2    | beijing 2008beijing 2008 | 1c0ddb82cca9ed63e1cacbddd3f74082 |
+------+--------------------------+----------------------------------+
1 row in set (0.00 sec)

合成インデックスは完全一致シナリオでのみ使用できます。これにより、ディスク I/O がある程度削減され、クエリ効率が向上します。 BLOB および CLOB フィールドに対してファジー クエリを実行する必要がある場合は、MySQL のプレフィックス インデックスを使用できます。つまり、フィールドの最初の n 列のインデックスを作成できます。例:

mysql> create index idx_blob on t (content(100));
Query OK, 0 rows affected (0.09 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> show index from t \G
*************************** 1. row ***************************
        Table: t
   Non_unique: 1
     Key_name: idx_blob
 Seq_in_index: 1
  Column_name: content
    Collation: A
  Cardinality: 3
     Sub_part: 100
       Packed: NULL
         Null: YES
   Index_type: BTREE
      Comment: 
Index_comment: 
1 row in set (0.00 sec)

mysql> desc select * from t where content like 'beijing%' \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t
         type: ALL
possible_keys: idx_blob
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 3
        Extra: Using where
1 row in set (0.00 sec)

(3)、不要な場合は大きな BLOB または TEXT フィールドを取得しないでください。

(4). BLOB または TEXT フィールドを別のテーブルに分割します。

3. 浮動小数点数と固定小数点数

浮動小数点数は、通常、小数部分を含む値を表すために使用されます。フィールドが
浮動小数点型
として定義されている場合、挿入されたデータの精度が列に定義された実際の精度を超える場合、挿入された値は実際に定義された精度の値に丸められてから挿入されます。エラーは報告されません。 MySQL では、浮動小数点数を表すために Float と double (real) が使用されます。 固定小数点数は浮動小数点数とは異なり、実際には文字列の形式で格納されるため、固定小数点数の方がデータをより正確に格納できます。挿入されたデータの精度が実際に定義された精度より大きい場合、MySQL は警告を発行しますが、データは挿入前に実際の精度に従って丸められます (従来のモードで挿入された場合は、エラーが報告されます)。 。 MySQL では、固定小数点数を表すために 10 進数 (または数値) が使用されます。

浮動小数点数を使用してデータを保存すると、エラーが発生します。高精度が必要なシナリオ (通貨など) では、データの保存には固定小数点数を使用する必要があります。例:

mysql> create table b (c1 float(10,2),c2 decimal(10,2));
Query OK, 0 rows affected (0.37 sec)

mysql> insert into b values (131072.32,131072.32);
Query OK, 1 row affected (0.00 sec)

mysql> select * from b;
+-----------+-----------+
| c1        | c2        |
+-----------+-----------+
| 131072.31 | 131072.32 |
+-----------+-----------+
1 row in set (0.00 sec)

四、日期类型

MySQL提供的常用的日期类型有：date、time、datetime、timestamp，日期类型的选用原则：

(1)、应根据实际需要选择能够满足应用的最小存储的日期类型；

(2)、如果要记录年月日时分秒，且年代比较久远，最好使用datetime类型；

(3)、如果记录的日期要被多时区的用户所使用，那么最好使用timestamp类型。

以上がMySQL のデータ型についての包括的な理解の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。