ブログの説明リンクします。https：//www.cnblogs.com/studynote/p/8079154.html
まず、データベースの設計パラダイム6
我々は、すべて聞いた：いくつかのデータベースの設計のパラダイムは、最も顕著な第3正規形であります。
1。最初のパラダイム（1NF）：属性切っても切れない
最初のパラダイムは、最も基本的なパラダイムです。データベーステーブルの値のすべてのフィールドは、アトミック値が分解されていない場合、それは最初のデータベーステーブルがパラダイムを満たすことを示しています。
2。第2正規形（2NF）：1NF、完全に機能的な依存関係を満たす
第二のパラダイムは、データベーステーブルと主キー（主要な用語のプライマリキー）の特定の部分にのみ関連していない関連する各列の主キー、それを確認する必要があります。データベーステーブルに、テーブルにはデータのみを保存することができます。つまり、我々は同じデータベーステーブルに格納されたデータの多様性を置くことはできません。
3。第三のパラダイム（3NF）：2NFを満たす、転写依存除去
三パラダイムは、データの各列とテーブル内のデータを直接ではなく間接的により主キーに関連していることを保証します。
4。BCパラダイム（BCNF）：3NFのコンプライアンス、および、メインプロパティは、主属性に依存しません。
第三のパラダイムに関係があり、それが唯一の候補コードである、またはそれは各候補コードのための単一の属性である場合には、自然なモデルBCとの関係に達しました。
5。第四に正規形（4NF）：BCNFに準拠は、同じテーブルで多くの関係を削除するように依頼しました。
6。第五のノーマル（5NF）：4NFコンプライアンスは、テーブルは、テーブル内のすべての冗長データを排除するために、できるだけ小さいブロックに分割されています。
第二に、抗正規化と標準化
ない最高のデザイン、唯一の最も適切な設計なので、理論を強調しすぎることはありません。
頻繁にアクセスされるデータとデータの頻繁な変更：データベース設計では、データは、2つのカテゴリに従って編成されるべきです。
頻繁にアクセスされるが、頻繁に変更されていないデータの場合、データテーブルのデザインは、非正規化すべきです。
頻繁な変更ではなく、頻繁にアクセスされるデータについては、データテーブルの設計が標準化されるべきです。
正規化されたテーブルは、時には、論理データベースの設計基準を必要とし、その後、アプリケーション全体のシステム、抗正規化を必要としました。
標準および抗規範両方実用ない感覚から、実際の動作単位に制約が確立されています。それぞれの利点を再生するために、互いを補完する2つの唯一の合理的な組み合わせ。
第三に、抗正規化法
設計テーブルでは、特定の抗標準化された方法を取ってテーブルには、以下のとおりである必要があります。
まず、パーティションテーブル。
：パーティションテーブルが2つである垂直分割レベルのテーブルとパーティションテーブルを分割することができ
、検索テーブルをスピードアップすることができそれぞれが、レベルのセグメンテーションは、複数のテーブルに分割テーブルに基づいて、異なるテーブルの更新を選択するためのクエリ統計あなたが複数のテーブルを集計する際に、そのアプリケーションがより複雑になります。
多くのテーブル列の垂直分割、一部の列アクセス頻度が他の列よりもはるかに高い場合は、テーブルとしてプライマリーキーやカラム、別のテーブルとしてプライマリーキーと他の列であってもよいです。列の幅を減少させることによって、それによって各テーブルへのアクセス速度を向上させる、1つのI / O線は、複数走査することができるデータのページあたりの行数を増加させます。しかしながら、得られたマルチテーブルに参加するので、同じ時間クエリにまたは比較的少数の症例の異なる列のパーティションテーブルの更新に使用されるべきです。
第二は、冗長列を保持することです。クエリ内の2つの以上のテーブルが頻繁に接続する必要がある場合、それは冗長列の複数が、テーブル間のあまりに頻繁な接続を回避するために、データが冗長列は、典型的には、まれにケースを変更し、前記テーブルに増加させることができます使用下。
第三は、派生列を増加させることです。他のカラムに由来するテーブル内の列の計算複数であり、列はデータ収集が大幅に計算時間を短縮することができる場合、派生統計的操作を増加させるために減少させることができます。
第四に、フィールドタイプの最適化
最適化の原則：
1.試し固定長テーブルが速くなるので、固定長の型を使用します。
テーブルのすべてのフィールドが「固定長」である場合、テーブル全体が「静的」または「固定長」であると考えられます。例えば、以下の表は、フィールドのないタイプではない：VARCHAR、TEXT、BLOB。限り、あなたはこれらのフィールドのいずれかが含まれて、その後、テーブルには、「固定長静的テーブル」ではありませんので、MySQLのエンジンはに対処するための別の方法を使用します。
MySQLの検索が速くなりますので、固定長テーブルには、固定長のデータにオフセット次の計算が容易であることから、それは当然早く読まれる、パフォーマンスが向上します。フィールドは固定長でない場合と、そう、次のいずれかを見つけるたびに、プログラムは、主キーを見つける必要があります。
そして、固定長テーブルもキャッシュされ、再建される可能性が高いです。しかし、唯一の副作用は、固定長フィールドを使用するかどうかを固定長フィールドがないので、彼は多くのスペースを割り当てるべきである、いくつかのスペースを無駄にするということです。
「縦割り」の手法を使って、あなたのテーブルには、固定長、可変長である二つに分割することができます。
2.小型、それは小さなコラムより速く、より省スペース収納があり、かつので。
たとえば、次の
代わりにINTの少ない可能使用MEDIUMINT、SMALLINT TINYINTまたは;
Bの代わりに良好DATETIME日付を使用してのデータのタイプにのみ正確な一日。
Cタイムスタンプ型の代わりに、DATETIME型を使用して、それがあるからです。 DATETIMEは、型の半分だけのストレージスペースが必要です
dは。INT UNSIGNEDとしてIPアドレスが保存されている
E. ENUMが代わりにVARCHARを使用しました。ENUMタイプは、非常に高速でコンパクトです。実際には、その保存はTINYINTですが、文字列として番組にその外観。その結果、オプションのリストの一部を行うには、このフィールドを使用することは非常に完璧になります。
データテーブルの第五に、合理的な設計
1.各テーブルには、常にIDが設定されている
、我々は、その主キーとしてIDに設定され、好ましくは、INT型（UNSIGNED推奨）、およびAUTO_INCREMENTフラグ自動上昇に設定されているデータベースの各テーブルにそれを借り。
2.インデックスの使用の合理化
全表スキャンを回避するために、クエリの最適化のためには、最初の場所と順番に関与列でインデックス作成を検討すべきです。インデックスは、対応するインデックスは確かに選択の効率を向上させることができ、可能ではないですが、また時に挿入または更新インデックスを再構築することが可能であるため、挿入および更新の効率が低下するので、慎重にインデックスを構築する方法を検討する必要がある、など場合であってもよいです。
NOTを使用し、できるだけ多くの3 NULL
NULLタイプは、SQLの最適化は、このような難易度のインデックスとして、困難であり、かなり特殊です。しかし、それはまた、空きスペースのNULL値が格納されているよりも多くのメモリを必要とするかもしれません。
第六に、SQL文の使用の合理化
1.避けSELECT *コマンドが返すのみ必要なフィールド
2.使用制限1は、一意の行作られた
、あなたはすでに結果が結果だけになりますが、知っているあなたは、カーソルをフェッチ行く必要がある、または可能性があるので、あなたが返されたレコードの数を確認しに行くかもしれないあなたがテーブルを照会する場合がございます。
この場合、パフォーマンスはLIMIT 1を共に向上させることができます。そのため、MySQLのデータベースエンジンは、データの一部を見つけた後、検索を停止する、というよりも少ないデータレコードに次の行を戻って確認していきます。
3.フィールドwhere句で決定されたヌル値に避けるべきであるが、例えば、エンジンがインデックスとフルテーブルスキャンを使用して放棄する原因となり
NUMがnull TからSELECT ID
4！=または<> where句演算子にしていないでは避けるべきである、または全表スキャンになります。
5.何のインデックスフィールド句が存在しないフィールドがある場合、エンジンがインデックスとフルテーブルスキャンを使用してあきらめてしまいます。
文字列LIKE「％のA」6.検索が優位性を取得するために、インデックスを使用して、「％」LIKE列をインデックスの利点を取得するために使用することはできません。
7.エンジンがインデックスとフルテーブルスキャンを使用してあきらめてしまうwhere句、内のフィールドオペレーションの表現を避けるべきです。例えば：
T / 2 = 100がどこからNUM IDを選択
読んでください：
NUM = 100 *のT 2つのどこからIDを選択
8.フィールドは、エンジンは、インデックスを使用して放棄する原因となり、where句で操作機能のために避けるべきです全表スキャン。例えば：
Tは、ストリングから（名前、1,3）= 'ABC' --name IDのABCは始めSELECT ID
TからIDを選択する場合DATEDIFF（日 、CREATEDATE、 '2005-11-30'）= 0 - '2005-11-30' -生成されたIDを
読み取る必要があります
名'ABC％が'のようなTからIDを選択し
、T> = CREATEDATE '2005-11-30'からIDを選択し、CREATEDATE <「2005-12- 1 '
9は、where句内の関数、算術演算、またはその他の式を実行しない『=』左、またはシステムが適切に索引付け機能しないことがあります。
結果は実用的ではないかもしれないので10、実数および他のタイプを使用して日付/時刻=演算子を避けます。
11.かのように避ける：
TからSELECT ID WHERE NUM = 10または名= 'ADMIN'
することができ、このクエリ：
SELECT IDのNUM WHEREからT = 10
・ユニオンのすべての
SELECT T WHERE名= 'ADMIN'からID
著者： ジングル郭
出典： http://www.cnblogs.com/studynote/
「復刻版」のタイトルは、この記事では、元の作者に属している場合。何の単語再版が存在しない場合は、この記事では、すべての作者に属し転載を歓迎しますが、この節で宣言され、作者の同意を得ることなく、それ以外の権利を法的責任を保持し、記事ページの見かけ上の位置に元の接続を指定する必要があります。