第IV章：スキーマのデータ型と最適化

データの最適化の種類を選択します

原則のデータ型を選択

小さい方は通常より良いです：正しくデータを格納できる最小のデータ型を選択します
- 小さなデータの種類は少ないメモリ、CPUを消費し、少ないディスクを取ります
単純なデータ型を使用します。単純なデータ型は、通常のプロセスに少ないCPUサイクルを必要
- ビルトインタイプのMySQLを使用すると、日付と時刻を格納します
- IPアドレスを格納する整数を使用します
NULL値を避けるようにしてください：通常の状況下では使用しないでヌルを、実際にはnull値を保存する必要がない限り、
- NULL値がインデックス、統計を行い、比較は値によって複雑にされています
- 列は、店舗nullに多くのスペースを必要とするかもしれません
- InnoBDは、単一ビットのNULL値を格納するために使用しました

：デジタルに分けて、整数と実数

1.1整数型

整数を使用することができる：TINYINT、SMALLINT、INT、記憶するためのBIGINT型は、それぞれ8,16,24,32,64ビットがUNSIGNED属性識別子整数使用してストレージスペースを占有、非負を表します。

TINYINT.UNSIGNED範囲0-255は記憶され、-128の範囲127 TINYINTにしてもよいです

MySQLはそれだけを格納する文字の数を表示するには、MySQLクライアントを提供し、ほとんどのアプリケーションでは意味がないため、彼は正当な値の範囲を限定するものではない、そのようINT（11）として、整数型の幅を指定することができますINT（11）とINT（20）は、同じ空間を占有しています。

1.2実タイプ

実数型の小数部分と実数は必ずしも小数、使用することができますよりも大きな整数小数保存bigint型を維持するために使用されていないです。

MySQLは、両方の正確な型も不正確な種類をサポートしているサポートされています。

標準的な浮動小数点演算を使用して、float型とdouble支持体は二重近似.FLOAT 4バイト、8バイトであり、MySQLは、内部の倍精度浮動小数点計算を使用して実行しました
小数点小数精度、正確な計算のサポートを格納するための、MySQLサービス層は、相対的に浮動小数点数に直接、CPUを話すので、スペースをより速くによって占有される、小数の正確な計算を達成するように、さらに、CPUは、小数点演算をサポートしていない.decimal倍以上。

MySQLは静かに店で異なるデータタイプ、またはトレードオフを使用するので、多くの方法が、倍精度浮動小数点の列を指定することができ、精度のタイプを指定せずにデータのみを指定することをお勧めします。スペースを考えるとオーバーヘッド計算のみ小数であるべきですこれは、現場で小数点以下を用いて計算しました。

1.3文字列型

MySQLは多くの亜種で、それぞれ、様々な文字列型をサポートしています。
VARCHAR、及びチャーは、文字列データの2つの主要なタイプ、データストレージと関連するストレージエンジンのこれら2つのタイプです。

1.3.1 varchar型

>省スペース - 文字列の辺の長さを格納するためのvarchar型は、それだけでデータの格納に必要なスペースを使用しています
ストアデータ長にさらに1又は2つのバイトを使用して、VARCHAR
これは、パフォーマンスの向上をもたらしますが、より長い実行時間の更新を引き起こす可能性もスペースを節約します
保存されたvarchar型とのシーンのために：
- 平均よりもストリング列長以上の最大長さ
- いくつかの更新列
- 複雑な文字セットを使用しています（UTF-8）

1.3.2 CHAR

炭化長が固定され、MySQLは文字列の長さに応じて規定された空間的分布を修正しました
char型は、断片化varchar型の面で、より多くの困難を埋めるために、スペースとの比較を容易にするために必要とされるであろう
チャーは近い列に短い長さまたは固定値を記憶するように適合しました
- MD5値は、パスワードが保存されています
- バイナリデータと比較する必要を格納すると、charが速くなります
任意のストレージエンジンは、充填及びそれがサービス層の実装であるため、スペースは、同じであるSNIP

1.3.3 BLOBとTEXTタイプ

MySQLは、設計の長い文字列にテキストやBLOB型で、格納されたバイナリ文字列です。
データが長すぎ、ストアへ外側領域InnoDBエンジンで使用される2つのタイプが、外側領域にラインポインタ内1-4バイトを使用します。

1.3.4文字列の代わりに、列挙型

場合列挙MySQLの非常にコンパクトに収納1つまたは2つ、「ルックアップテーブル」のMySQLに格納されたマッピング関係にサイズの圧縮後のバイト数に基づいた値のリスト - の関係「数字列」。

mysql>create table enum_test(
    e ENUM('fish','apple','dog')not null
);
mysql> insert into enum_test(e)values('fish','dog','apple');

データこれらの3つの行は、実際の整数として格納されています。

mysql> select e+0 from enum_test;

+---+
|e+0|
+---+
|  1|
|  3|
|  2|
+---+

アメリカのテレビは、ローカルテーブルの活用ではありません変更する必要がある場合、文字列の固定リストで削除して再構築する必要があります。
いくつかのケースでは、char型のvarchar型の協会/およびパフォーマンスの低下を引き起こす可能性があり、列の列挙。

1.4日付と時刻タイプ

秒を保存することができますMySQLの最小時間単位は、使用済みのマイクロ秒の粒度一時的操作であってもよいです。

1.4.1 DATETIME

1001から9999、第2のビット精度に、広い範囲の値を保存します。
フォーマット：YYYYMMDDHHMMSS、ストレージの8つのバイト

1.4.2 TIMESTAMP

UNIXタイムスタンプと1970年1月1日0時からの秒数として保存。
スペースの4つのバイトは、唯一の1970- 2038年を保存することができます
表示された値に依存する地域
デフォルト値はヌルであり、デフォルト値はこの列の現在時刻値として挿入されていません

さらに、保存された時間がBIGINT値より小さい粒径を使用することができます

1.5データ型

MySQLは、このようなビットセットとして、データの種類を格納するために数ビットを使用した後、およびかかわらず、基礎をなす記憶フォーマット及び方法の技術的文字列です。

1.6選択識別子

ID列は、他の列と比較するために使用することができる、または他の列を探すことによって識別される列は、列が外部キーで識別することができます。

値の範囲を満足させなければならない最小のデータ型を選択し、列の種類として特定の将来の成長のスペースを確保するために：

整数型は使用auto_increamentすることができ、一般的に良いタイプです。
通常の状況下で、我々は唯一の固定情報を格納するのに適しているどちらも、列挙およびセットの使用はお勧めしません。
文字列の使用を避け、そして、より多くのスペースを消費する整数型より遅いと比較され、

トラップのスキーマ内2.MySQLデザイン

あまりにも多くの列
- バッファラインのデータ形式のエンジンコピーによってサービス層と記憶層との間に必要なMySQLストレージエンジンAPI作業は、サービス層が各列、復号化プロセス中に異常な消費性能にバッファの内容を復号します。
あまりにも多くの協会
- （EAV）デザインパターンの仕事MySQLでは良い「 - - 属性値実体」を作ることができません。
- それぞれに関連するMySQLの制限は、61のテーブルまで動作しますが、EAVデータベースは、自己会合の多くを必要とします。
- 経験は、12テーブル関連MySQLの効率内の最高のいくつかを示しています。
全能の列挙
- 価格が高いだろう変更するために一度防止列挙の過度の使用は、自然の缶として列挙はない修正されます。
偽装列挙
- コレクションセットの列が1つ以上の値を可能にする、この時間は簡単に混乱を招きます：
```
create table ...(is_default set('Y','N') not null default'N');
```
  真実がある場合は、両方のケースで同時に発生していないし、列挙を使用することがより適切であろう。
このnull以外の本発明
- 一般的に真の、使用、または0は、空の文字列などの特定の値を置き換えるために使用することができる場合であっても、NULL値を使用しないことが推奨されます。

3.パラダイムとカウンターパラダイム

すべてのデータは、データベースのパラダイムに表示され、一度だけ、およびデータカウンタ・パラダイムは、すべての事実は何回か、情報の冗長性を表示されることがあります。

3.1パラダイムの長所と短所

標準の設計パラダイムの性能に応じて書き込み集約型のテーブルが良くなります！

パラダイム速くアップデート
より良いデータの正規化、非常に少ないデータはわずか数のデータを更新する必要があることを意味冗長であり、
パラダイム少しデータの冗長性、あなたがより良く、より速くメモリ動作を置くことができ、より少ないスペースを取ります
別個の周波数によってより少ない冗長グループと低下します

3.2アンチパラダイムの長所と短所

表中の抗パラダイムのデータ、それは回避協会に良いことができます。
あなたが関連付けられていない場合は、（インデックスがない場合でも）遅いほとんどのクエリのフルテーブルスキャンを必要とするデータが大きい場合には、その後、メモリ全表スキャンは、はるかに高速協会よりかもしれより。

3.3ミックスパラダイムとカウンターパラダイム

最も一般的な抗パラダイム設計は、同じ表の異なる列に格納され、コピーまたはキャッシュされています。
MySQL5.0の後トリガーでキャッシュを更新することができます。

そして、キャッシュテーブル4.まとめ

パフォーマンスを向上させるために時々の最善の方法は、テーブル内の書き込み冗長データ保存導出されていますが、いくつかの点で、必要性は、完全な集計表やキャッシュテーブルを作成します。

キャッシュ：取得が比較的単純であることができる（表当たりのより遅い取得レート）テーブルスキーマ内の他のテーブルから（表論理的冗長）データ
要約：文データ（冗長データではない論理）によって格納されたテーブル重合性基を使用して。

5.まとめ

デザインをオーバーしないようにしてください

適した小型でシンプルなデータ型、回避のヌル値

データストレージ関連列の同じまたは類似のタイプを使用しようと、特にカラム関連する状態

その変数の長さの文字列に注意してください。

アイデンティティを定義した整数列を利用します

MySQLのすでに放棄されたプロパティを使用しないでください

列挙セットを使用するように注意してください、最高の回避ビット

パラダイムは良いですが、多くの場合、カウンターパラダイムが必要であり、この時間は、利益をもたらします