最適化の前の問題は、データベースレベルのデータの数百万を尋ねてきた、そしてサブサブテーブルのライブラリーは、重要なポイントの一つです。
コンセプトや戦略ポイントテーブル
大規模なインターネットアプリケーションでは、単一のデータベーステーブルの行数は、千万かさえ億に達する可能性があり、データベースが高い同時アクセスに直面しています。MySQLのアーキテクチャのメインモード（マスタ・スレーブ）からコピーし、データベースが読み取り専用ことができる拡張し、データベースへの書き込みは、マスター上でクラスタ化され、シングルマスタスレーブは、無制限の複数をマウントすることはできませんスレーブマスター限られた容量と負荷の数。したがって、高い同時アクセスと大容量データ記憶装置のニーズを満たすためにデータベースの処理能力のさらなる拡大の必要性。
大量のデータへのアクセスは非常に頻繁にシングルテーブル（百万から千万レベル）で、まず最初にすることは、データのクエリに必要な時間を短縮し、データベースのスループットを向上させるために、単一のテーブル内のレコードの数を減らすことで、これは、パーティションテーブルの概念です。サブテーブルには、最初にデータをより均等に複数のテーブルに分散することができるように、適切なサブテーブルの戦略を選択する必要があり、通常のクエリに影響を与えることができません。
インターネット企業のために、データのほとんどは、ユーザーに関連付けられているので、ユーザーIDは、最も一般的なサブテーブルのフィールドであるされています。クエリのほとんどは、ユーザーIDを持参する必要があるので、そのようなサブテーブルの戦略は、通常のクエリには影響しませんが、また、より均等に各テーブルに分散されたデータを作るために（いくつかのシーンは、ホットとコールドデータの偏在は例を表示されますがあります） 。
ORDERテーブルの数があまりにも多くのレコードが、テーブルは（テーブルの数は、典型的には、2のN乗に分割されている）256に分割する必要があるため、利用者の購入注文情報（ORDER）を記録するために使用されるテーブルがあるとし、分割規則は、％256 USER_IDレコードを記憶する対応テーブルに従って取得されます。フォアグラウンドアプリケーションがルールUSER_ID％を256に応じて、対応する順序記憶テーブルを見つけることができ、そして再度データを取得する履歴テーブルに格納される（残りは、次いで、ルックアップテーブル番号0であり、そして残りは233であり、ルックアップテーブル233） 。このように、USER_IDは、それ以外の場合は、彼らが保存されたデータテーブルがデータにアクセスすることはできません見つけることができないだろうので、必須のクエリ条件となります。
あなたがアクセスすることをUSER_ID注文レコードが257である、あなたは、テーブルへのアクセスを取得したい場合は、この時点では、USER_ID％の256個のルールに従ってORDER_1です。257人のユーザー、特に富裕層、次億件の受注、ORDER_1テーブルは、それが大量のデータを提供しているならばここで、つまり、質問があるかもしれません。もちろん、このような状況の現実はそうではありませんが、問題は、特定のサブテーブルの戦略は実際の状況に基づいて開発されるべきであること、ビューを起動することができます。
概念と戦略は、サブライブラリー
過度な単一テーブルのデータのクエリ効率の減少によって引き起こされる問題を解決するためのサブテーブルが、それはデータベースの同時処理能力に質的な改善をもたらすことができません。マスター・データベース・サーバーは、拡張子に関係なくスレーブサーバの、書き込み圧力を運ぶことができない高同時読み取りおよび書き込みアクセスの顔は、意味がありません。考え方を変える必要がある：死ぬために、複数のテーブルを分割するので、サブライブラリーの概念であり、全体的な書き込み能力を向上させるための複数の単一のデータベースを書く収集する機能、複数のデータベースを分割する方が良いだろう。
同様の戦略とサブテーブルは、サブライブラリーは、経路データアクセスにモジュロキーワードの方法によって使用されてもよいです。、USER_IDフィールドは258の値は、ライブラリーは、元の単一のライブラリ256に分割されているものとする前またはOrdersテーブルたとえば、データベース・リクエストへのアプリケーションアクセスは、第2ベース（258％2 = 256）にルーティングされます。
概念と戦略は、サブライブラリーのサブテーブル
時間のほとんどは、データベースには、高い同時アクセスの圧力と大容量データストレージの問題に直面するだろう。今回はサブテーブルの戦略だけでなく、システムの並行処理能力の両方を拡張するだけでなく、単一テーブルのクエリのパフォーマンスを向上させるためにサブライブラリー戦略の使用を使用する必要があります。この方法でサブテーブルのサブライブラリーとの共同使用は、サブライブラリーのサブテーブルの概念です。
次のようにサブライブラリーサブテーブルルーティング戦略は、より複雑にのみサブライブラリーのみサブテーブルと比較ポリシーサブライブラリーサブテーブル戦略：
1.中間変数= USER_IDの％（*サブライブラリ各ライブラリテーブル番号の数）
2.ライブラリ=丸め（中間変数/各ライブラリのテーブル番号）
各ライブラリー内のテーブルの表3％=中間変数の数
また、表には、各ライブラリー*は、ルーティングフィールドとして第1の使用USER_IDライブラリの数を同じユーザIDの中間変数を取得するために、テーブルの数を法として使用して、オーダーである。次いで、中間変数丸め、データベース当たりのテーブルの数を使用することによって、我々は、対応するライブラリを与える;各中間変数は、対応テーブルを取得するために、データベーステーブルの数を法。
：つのデータベース・テーブル内の元の単一のテーブル256 ORDERライブラリ、テーブル1024を含む各ライブラリ、前述のルーティングポリシー、アクセスUSER_ID = 262145を算出する処理は、以下のルートを分割するとし
1.中間変数= 262145パーセント（* 256 1024）= 1
2.ライブラリ=（1/1024）= 0丸め
3.表1％= 1024 1 =
USER_ID =クエリと262145件の注文のレコードを変更するための第1の1 ORDER_1表0ライブラリの実行にルーティングされます、ということになります。
「私は非常に多くの理由を知っているが、それはこの人生でまだあまりにも悪いです。」