サブライブラリーのレベル
1、概念：特定のポリシー（ハッシュ、範囲、等）に応じてフィールド単位は、複数のライブラリのデータベースにデータを分割します。
2結果：
各ライブラリの構造と同じであり、
各ライブラリーのためのデータが同じではない、何の交差点が存在しない、
すべてのライブラリとデータの全体量を設定する;
3、シーン：同時アップのシステム絶対量は、サブテーブルは、基本的に解決することは困難です問題、および垂直方向のライブラリを確定する明白な。
4.分析：自然のライブラリより、IOとCPU緩和圧力を掛けすることができます。
サブテーブルのレベル
1、概念：特定のポリシー（ハッシュ、範囲、等）に応じてフィールド単位は、複数のテーブルのテーブルにデータを分割します。
2結果：
各テーブルの構造は同じであり、
各テーブルのデータが異なり、全く交差が存在しない、
全てのテーブルが満杯とデータ量に設定されている;
3、シーン：並行システムの絶対量が来ない、ただ1つのデータテーブルあまりにも多くのボリュームは、SQLの効率に影響を与え、ボトルネックとなり、CPUの負担を増加させました。
4.分析：データテーブル少なく、かつ高い単一のSQL実行効率、自然にCPUの負担を軽減。
垂直ライブラリー
1は、概念：テーブルのベースと、別の権利確定に応じて、異なるテーブルは、異なるライブラリーに分割されます。
2.結果：
;ライブラリーのそれぞれの構造は同じではありません
。何の交点が存在しない、各ライブラリのデータが同じではない
すべてのライブラリと設定されているデータの全体量;
3、シーン：システムアップ絶対並行処理は、単独で抽象的でありサービスモジュール。
4.分析：この時点で、あなたは基本的にサービスのことができます。例えば、より多くのビジネスの発展いくつかの一般的な構成テーブル、ディクショナリ表などで、その後のテーブルが別のライブラリに分割することができ、あるいはサービスなど。さらに、インキュベーターのビジネスモデルのセットの開発と、それは、あるいはサービスとしてライブラリに関連する別のテーブルに分割することができます。
垂直のテーブル
1、概念：フィールドが計算され、フィールド活動に応じて、別のテーブルにテーブル内の分割フィールド（プライマリ・テーブルと拡張テーブル）。
図2に示すように、結果は：
2.1、各テーブルの構造は同じではない、
2.2、データが各テーブルに同じではない、一般的に、各テーブルのフィールドは、少なくとも一つの交差点を有し、一般的には、関連するデータの主キーであり、
2.3 、すべてのテーブルは、セットデータの総量であり、
図3に示すように、シーン：並行システムの絶対量がアップ、記録紙があまりないのではなく、マルチフィールド、非ホットスポット及びホットスポットデータ及びデータと共に、データ記憶空間の単一の行が必要大きい方。データベースキャッシュラインのデータ削減するように、IO、IOボトルネック農産物を読み取るために、ランダムなクエリの多くを生成するために、ディスクのデータを読み込みます。
4.分析：リストページと詳細ページを理解するために使用することができます。垂直解像度原理は、拡張テーブルとして一緒に、一緒に主テーブルとして（冗長データが頻繁に一緒に照会することができる）は、非ホットスポットデータホットテーブルデータです。このような追加のデータは、それによってランダム読み取りIOの削減、ホットキャッシュすることができます。解体した後、すべてのデータを取得するためには、データをフェッチするために2つのテーブルを関連付ける必要があります。
しかし、一緒に結合された2つのテーブルを唯一のCPUの負担を増加させない参加と話すので、使用は（データベース・インスタンスである必要があります）、参加していない、覚えています。リンクされたデータサービス層は、それぞれ一次及び拡張テーブルデータを取得し、関連するフィールドに関連付けられたすべてのデータを取得、ビジネスで問題なければなりません。