MySQL データ型の理解

MySql データ型の理解:

MySQL の独自の特性と実装の詳細により、 Mysql データベースを適切に設計することが重要であるため、パフォーマンスへの影響は明らかです。データベース設計ではテーブルフィールドの型選択が重要ですが、Mysql は多くのデータ型をサポートしているため、高いパフォーマンスを得るには正しいデータ型を選択することが重要です。保存したいデータの種類に関係なく、データベース設計原則に従って考慮する必要があります。

データ型の選択について考える

通常は小さいほど良いです (一般に、可能な限り、データを正しく格納できる最小のデータ型を使用する必要があります)

＃＃＃なぜ？

(1) データ型が小さいほど、占有するディスク、メモリ、CPU キャッシュが少なくなり、処理に必要な CPU サイクルが少なくなるため、一般に高速になります。

(2) 保存する必要がある値の範囲を過小評価しないように注意してください。小さい値は、データ型の最大値の範囲に比例します。
(3) どのデータ型が最適であるかを判断できない場合は、範囲を超えないと思われる最小の型を選択してください。

シンプルであることは良いことです (単純なデータ型の操作には通常、より短い CPU サイクルが必要です。)

なぜですか?その理由を説明するために、いくつかの例を示します。

(1) 文字列セットの文字比較と照合規則 (並べ替え規則) は整数比較よりも複雑であるため、整数演算は文字列演算よりもコストがかかりません。

(2) 日付と時刻を保存するには、Mysql の組み込み型 (日付、時刻、データ時刻) を使用する必要があります。
(3) IPアドレスは整数型(int)で格納してください。

NULL (null 値) は避けてください

なぜですか?

(1) プログラムで NULL を保存する必要がない場合でも、多くのテーブルには NULL になる可能性のある列が含まれています。これは、列のデフォルト属性が NULL になる可能性があるためです。本当に NULL を格納する必要がない限り、通常は列に NOT NULL を指定するのが最善です。

(2) クエリに NULL になる可能性のあるカラムが含まれている場合、NULL カラムによってインデックス、インデックス統計、および値の比較がより複雑になるため、Mysql による最適化が困難になります。 NULL にできるカラムはより多くのストレージ領域を使用するため、Mysql での特別な処理が必要になります。 NULL 許容カラムにインデックスを付ける場合、各インデックス レコードに追加のバイトが必要となるため、MyISAM では固定サイズのインデックスが可変サイズのインデックスになる場合もあります。
(3) 通常、NULL 対応列を NOTNULL に変更してもパフォーマンスはほとんど向上しません。列にインデックスを構築する予定がある場合は、NULL 対応列として設計しないようにしてください。 (例外があります。InnoDB では、NULL 値の格納に別のビットが使用されるため、スパース データに対して優れたスペース効率が得られます。)

概要

列のデータ型を選択するとき、最初のステップは適切な大きな型 (数値、文字列、時間など) を決定することです。これは通常非常に簡単で、次のステップは特定の型を選択することです。

多くの Mysql データ型は同じタイプのデータを格納できますが、ストレージの長さと範囲、許容される精度、または必要な物理スペース (ディスクおよびメモリスペース) が異なります。同じ大きな型のデータの異なるサブタイプには、特別な動作やプロパティがある場合があります。例: データタイム そして TIMESAMP 列は同じタイプのデータ (時刻と日付) を格納でき、秒単位で正確ですが、TIMESTAMP は DATATIME の記憶領域の半分しか使用せず、タイム ゾーンの変更に基づく特別な自動更新機能を備えています。さらに、TIMESTAMP で許可される時間範囲ははるかに小さく、場合によってはその特殊な能力が障害となる可能性があるため、開発者はそれを考慮する必要があります。

整数型

数値には整数と実数の 2 種類があります。

整数を格納する場合は、TINNYINT (8)、SMALLINT (16)、MEDIUMINT (24)、INT (32)、BIGINT (64) の整数型を使用できます。

整数型にはオプションの UNSIGNED 属性があり、負の値は許可されないことを意味します。これにより、正の数の上限がおよそ 2 倍になる可能性があります。

例: TINYINT UNSIGNED は 0 ～ 255 の範囲を格納できますが、TINYINT の格納範囲は -127 ～ 128 です。

符号付き型と符号なし型は同じ記憶領域を使用し、同じ機能を持ちます。 .

したがって、実際の状況に応じて適切なタイプを選択できます。

あなたの選択によって、Mysql がメモリとディスクにデータを保存する方法が決まります。

Integer は、32 ビット環境であっても、通常は 64 ビット BIGINT 整数を選択します。 (ただし、一部の集計関数は例外で、DECIMAL または DOUBLE を使用して計算されます)

Mysql は整数型の幅を指定できます。

例: INT (11)、これはほとんどのアプリケーションにとって無意味です。値の法定範囲を制限するものではなく、Mysql の一部の対話型ツール (Mysql コマンド ライン クライアントなど) を規定するだけです。 used 表示される文字数。保存と計算の目的では、INT(1) と INT(20) は同じです。

一部のサードパーティ ストレージ エンジン (Infobright など) には、カスタマイズされたストレージ形式や圧縮スキームが含まれる場合がありますが、これらは必ずしも一般的な Mysql 組み込みエンジンを使用するとは限りません。

#実数型

実数とは、小数部を持つ数値です。

将来の小数部分を保存するだけでなく、DECIMAL を使用して BIGINT より大きい整数を保存することもできます。 Mysql は、正確な型と不正確な型の両方をサポートします。 DECIMAL 型は、正確な小数を格納するために使用されます。

精度演算は Mysql5.0 以降のバージョンでサポートされていますが、Mysql4.1 以前のバージョンで浮動小数点演算を使用すると例外が発生します (主に精度の損失が原因です)。進行状況を指定します。

DECIMAL 列の場合、小数点の前後に許可される最大桁数を指定できます。これは列のスペース消費に影響します。 FLOAT (浮動小数点) カラムに必要な精度を指定する方法は数多くあります。これにより、Mysql は別のデータ型を静かに選択したり、格納時に値を四捨五入したりしますが、これらの精度は標準外であることが多いため、一般に、指定されたデータ型は精度を指定しないことのみを推奨します。

追加のスペースと計算オーバーヘッドが必要となるため、小数の正確な計算を実行する場合にのみ DECIMAL を使用するようにしてください。たとえば、財務データを保存する場合、データ量が比較的大きい場合は、DECIMAL の代わりに BIGINT を使用し、保存する通貨単位に小数点以下の桁数に応じた倍数を乗算することを検討できます。 FLOAT 型と DOUBLE 型は、標準の浮動小数点演算を使用した近似計算をサポートします。

文字列型

Mysql は複数の文字列型をサポートしており、各型には多くのバリアントがあります。このうち、VARCHAR と CHAR の 2 つの主要な文字列型です。

注: Mysql ストレージ エンジンが CHAR または VARCHAR 値を格納する方法はメモリ内とディスク上で異なる場合があるため、Mysql サーバーがストレージ エンジンから読み取る値は、別のストレージ形式に変換されます。

VARCHAR 型は可変長文字列の格納に使用され、最も一般的な文字列データ型です。

VARCHAR は、必要なスペースのみを使用するため、固定長タイプよりもスペース効率が高くなります (文字列が短いほど、使用するスペースが少なくなります)。

VARCHAR では、文字列の長さを記録するために 1 バイトまたは 2 バイトの追加バイトが必要です。

VARCHAR はストレージ領域を節約するため、パフォーマンスの向上に役立ちます。

次に、VARCHAR の使用に適したいくつかのシナリオを示します。

(1) 文字列列の最大長は、平均の長さよりも大幅に長くなります。
(2) 列はめったに更新されないため、断片化は問題になりません。
(3) は UTF-8 などの複雑な文字セットを使用しており、各文字は記憶域に異なるバイト数を使用します。

CHAR 型は固定長です。 (Mysql は常に、定義された文字列の長さに応じて十分なスペースを割り当てます)

CHAR は、非常に短い文字列、またはすべての値が同じ長さに近い文字列を格納するのに適しています。

VARCHAR および CHAR に似た型には、バイナリ文字列を格納する BINARY および VARBINARY があります。

注: VARCAHR(5) と VARCHAR(200) を使用して「hello」を格納する場合のスペース オーバーヘッドは同じですが、短い列を使用する利点は何でしょうか? (これは大きな利点であることがわかります)

Mysql は通常、内部値を保持するために固定サイズのメモリ ブロックを割り当てるため、カラムが長くなると、より多くのメモリが消費されます。これは、並べ替えや操作にメモリ内の一時テーブルを使用する場合に特に問題になります。ディスク一時テーブルを使用して並べ替える場合も同様に問題が発生します。

注: 最終的に、最善の戦略は、本当に必要なスペースのみを割り当てることです。

BLOB 型と TEXT 型

BLOB と TEXT はどちらも大きなデータを格納するために設計された文字列データ型で、それぞれバイナリ モードと文字モードで格納されます。

実際、これらはデータ型ファミリーの 2 つの異なるグループに属しています: 文字列型には TINYTEXT、SMALLTEXT、TEXT、MEDIUMTEXT、LONGTEXT が含まれ、

バイナリ型には TINYBLOB、SMALLBLOB、BLOB、MEDIUMBLOB、 LONGBLOB;

ENUM 型

文字列型の代わりに列挙型 (ENUM) を使用できます。多くの場合、一般的に使用される文字列型の代わりに列挙列を使用することが推奨されます。

(1) 列挙列は、事前定義されたコレクションにいくつかの一意の文字列を格納できます。

(2) MySQL は列挙型を格納する際に非常にコンパクトであり、リスト値の数に応じて 1 バイトまたは 2 バイトに圧縮されます。
(3) MySQL は内部的にリスト内の各値の位置を整数として保存し、「数値と文字列」のマッピング関係の「ルックアップ テーブル」をテーブルの .frm ファイルに保存します。

注: 驚くべきことの 1 つは、列挙型フィールドが、定義された文字列ではなく、内部に保存された整数によって並べ替えられることです。

注: 列挙型の最悪の点は、文字列リストが固定されていることです。文字列の追加または削除には ALTER TABLE を使用する必要があるため、将来の文字列で変更される可能性のある一連の文字については、要素をリストの末尾にのみ追加できることを受け入れない限り、列挙型を使用することは良い考えではありません。

注: MySQL は各列挙値を整数として保存し、それを文字列に変換するために検索を行う必要があるため、列挙型カラムにはある程度のオーバーヘッドが発生します。

日付と時刻のタイプ

Mysql には、YEAR や DATE など、日付と時刻の値を保存できる型が多数あります。

Mysql が保存できる最小時間粒度は秒です (MariaDB はマイクロ秒レベルのイベント タイプをサポートします)。ただし、MySQL はマイクロ秒レベルの粒度でアドホック操作を実行することもできます。

ほとんどの場合、このタイプに代わるものはないため、何が最善の選択であるかについては疑問の余地はありません。

次の唯一の質問は、日付と時刻を保存するときに何をする必要があるかです。

DATETIME

(1) この型は、1001 から 9999 までの広範囲の値を秒の精度で保存できます。
(2) DATETIME は、タイム ゾーンに関係なく、時刻と日付を YYYYMMDDHHMMSS 形式の整数にカプセル化します。
(3)DATETIME は 8 バイトの記憶領域を使用します。

TIMESTAMP

(1) TIMESTAMP 型には、1970 年 1 月 1 日の午前 0 時からの秒数が格納されます。これは UNIX タイムスタンプと同じです。
(2) TIMESTAMP は 4 バイトの記憶領域しか使用しないため、その範囲は DATETIME よりもはるかに小さくなります。
(3) TIMESTAMPで表示される値はタイムゾーンによって異なります。

DATETIME と TIMESTAMP の比較:

(1) デフォルトでは、挿入時に最初の TIMESTAMP カラムの値が指定されていない場合、Mysql はこのカラムの値を現在時刻に設定します。 (これは DATETIME にはない機能です)
(2) レコードの行を挿入すると、Mysql はデフォルトで最初の TIMESTAMP カラムの値も更新します。
(3) TIMESTAMP 列のデフォルトは NOT NULL であり、他のデータ型とは異なります。

概要

(1) 特殊な動作に加えて、DATETIME よりもスペース効率が高いため、一般に TIMESTAMP を可能な限り使用する必要があります。
(2) 一般に、UNIX タイムスタンプを整数値として保存することはお勧めできません。これには何のメリットもありません。タイムスタンプを整数形式で保存すると、通常、処理が不便になります。
(3) 秒よりも小さい粒度で日付と時刻の値を保存する必要がある場合は、BIGINT 型を使用してマイクロ秒レベルのタイムスタンプを保存するか、DOUBLE を使用して秒以降の小数部分を保存できます。 Mysql の代わりに MariaDB も使用します。

ビット データ型

BIT は単一ビットを含むフィールドを定義し、BIT(2) は 2 ビットを格納し、最大長は 64 ビットです。

注: 一般に、BIT タイプは注意して使用することをお勧めします。ほとんどのアプリケーションでは、このタイプの使用を避けることが最善です。

識別子の選択

識別子 (ID 列) に適切なデータ型を選択することが非常に重要です。

一般に、ID 列を使用して他の値と比較したり、ID 列を通じて他の列を検索したりする可能性が高くなります。

ID 列のタイプを選択するときは、ストレージ タイプだけでなく、Mysql がこのタイプに対して計算と比較を実行する方法も考慮する必要があります。

タイプを選択したら、関連するすべてのテーブルで必ず同じタイプを使用してください。

値の範囲要件が満たされ、将来の拡張の余地が確保されていることを前提として、最小のデータ型を選択する必要があります。

注: 通常、整数は高速で AUTO_INCREMENT を使用できるため、ID 列には最適な選択です。注: ENUM と SET は最悪の選択です。これらはスペースを消費し、一般に数値型よりも遅いため、文字列を ID 列として使用することはできれば避けてください。

全文の要約

データベース設計では、決定を下す前によく考えてください。最適なデータ列の種類の選択とサイズの決定データ列の内容は非常に重要であり、重要なステップです。実際、パニックになる必要はありません。どのような種類の要件に合わせたデータ テーブルの設計に関係なく、覚えておく必要があるのは 1 つの原則だけです。これは非常に重要で、非常に重要で、非常に重要です。それは、正しく格納できる最小のデータ型を使用するということです。可能な限りデータを。

上記はすべて、MySQL データ型の理解に関するものです。

関連資料PHP 中国語 Web サイト

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