最近、このような状況、データの絶えず上昇量につながるため、長期的な蓄積にデータベース内のデータ、が、システムのページングクエリ効率の背景がたくさん削減されるたびに遭遇しました。その後、私は一瞬見て、主に伝統的な物理ページ制限N、Mの方法を使用しているこの場合は、原則としてページを見つけました。
プレゼンテーションを容易にするために、私は意図的に、次の表の演習のいくつかの例を作成しました：
Productテーブル、ユーザテーブルテーブルあり、テーブルには、商品を購入するユーザーを記録します。
商品利用者g_u
内部g_uに記憶された関係比較的単純な3つのテーブル、合成品及び関連するデータの内部に生成されたユーザのID番号、。以下の3つのデータベースのテーブルのデザイン：
シミュレーションシナリオは、ユーザーと製品との間の関係は、多くの団体に維持され、非常に簡単です。その後のテストを容易にするために、私は190万JMeterのテストデータボリュームを作成し、百万データクエリシーンをシミュレートします。
次いで、従来のページングクエリ操作のために、一般の人々は次の文を通じてかもしれない方法を考えるだろう、今、このようなビジネスシナリオニーズがあることを、我々は、テーブル内のデータの購入記録に対してクエリをページングする必要があると仮定します。
SELECT * from g_u as gu ORDER BY id limit 1850000,100
复制代码テストは、クエリの時間があることがわかりました。
我々は背中に、より多くのデータを検索すると、検索の速度がより低くなりますので、インデックスを作成するための適切なこの時間は、より重要になってきます。
まず、我々は次のように一度テストしたSQLは、試験結果を説明し実行します。
問合せキーがPRIMARYときに私たちの調査の時以来、したがって、主キーインデックスIDに従ってソート使用して、と。
SELECT * FROM g_u WHERE id >=(SELECT id FROM g_u LIMIT 1850000,1) ORDER BY id LIMIT 100
复制代码この時点で、多くのクエリの一部は改善したが、まだスロークエリました
分析結果は、実施計画を通して見ることができるについて説明します。
サブクエリはインデックスを使用し、外側のクエリはどこセカンダリインデックスを使用しています
この時間は、私たちは、クエリの効率を向上させるために、主キーIDを使用して、それを試してみたいことがあります。
SELECT * FROM g_u as gu WHERE gu.id>($firstId+$pageSize*$pageSize) limit 100
复制代码大幅に突然たくさんのすべてを、クエリの時間を短縮します：
して、SQLを分析について説明します。
主キーのインデックスのサービス、効率が大幅に改善されるようにする場合があり、SQLが実行されています。
しかし、この時間は、あなたは、このような疑問を持っていることがあります。インデックスデータが連続していない場合はどのように改ページを処理するときに、データの整合性と一貫性の各ページ？
ここでは、思考の別の種類を試してみてください、サードパーティ製のテーブルg_u_indexテーブルの確立を通じて、もともとg_u_indexに記憶されているIDをスクランブル、テーブルには、我々はテーブルを渡すことができg_u_indexはg_u_index.idを命じました対応する元の無秩序g_u.idに対応します。次のようにテーブルを作成するSQL文は次のようになります。
CREATE TABLE `g_u_index` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`index` int(11) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `idx_id_index` (`id`,`index`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1900024 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
复制代码PS：あなたは、クエリの効率を高め、idとインデックスの両方の複合インデックスを構築することができます。
ここでは、g_u_indexテーブルを挿入するデータ列と順序の必要性が同じで挿入し、それは、g_uテーブルであることを確認する必要があります。あなたがそう確認することができたときに、指定したインデックスページを照会：
SELECT g_u_index.index FROM g_u_index WHERE id=($firstId+$pageSize*$pageSize) limit 1
复制代码次のように分析を説明行うことで、結果は次のようになります。
問合せ時間：0.001s
：上記のサードパーティ製のテーブルの助けを借り、次の方法で調整することができるページングSQLの最適化と
SELECT * FROM g_u as gu where gu.id>(
SELECT g_u_index.index FROM g_u_index WHERE id=($firstId+$pageSize*$pageSize) limit 1
) limit 100
复制代码サードパーティ製のテーブルによる建物の後、クエリ時間のデータが突然大幅に削減します：
より人間のために照会すると、通常必要な、これらの無意味なIDを表示する必要はありません我々は唯一のサードパーティ製のテーブル、クエリなしで最も原始的な方法を使用することを想定して、商品名やユーザー名で、それは下に、より効率的になります：
SELECT gu.id,goods.`name`,`user`.username FROM g_u as gu ,goods ,`user`
where goods.id=gu.g_id AND `user`.id=gu.u_id
ORDER BY id limit 1500000,1000
复制代码結果：
したがって、サードパーティテーブルのクエリを使用する場合、次に、SQLは、この種の底に調整することができます。
SELECT goods.`name`,`user`.username FROM g_u as gu ,goods ,`user`
where goods.id=gu.g_id AND `user`.id=gu.u_id
and
gu.id>=(
SELECT g_u_index.index FROM g_u_index WHERE id=(9+1000*1900) limit 1
) limit 100
复制代码これは、大幅にクエリの時間を短縮します。
その後、実施計画を説明することにより、以下のように、結果は以下のとおりです。
実際のビジネスシナリオでは、そこに、このようなIDの分割を作成し、サードパーティのテーブルに同期するために百万元のテーブルのデータはここでは、あまりにも簡単にされている考えをお勧めします、我々は中央のアリを利用することができます送り部材の管は、データベース・ログの達成、及び、データの同期の動作をカスタマイズしています。
アリ運河予備練習フレームワーク（データ同期ミドルウェア）：私の記事で説明する運河は約もあります
SQLの最適化のために、実際のビジネスの組み合わせが一般的で、実行する必要があります必要があり、この部分はまだ強くなるために、いくつかの実用的な運動を持っている必要があります。
SQLの一般的な最適化技術（Javaのネットワークへの自己参照してください）概要：
1.大量のデータを、あなたは、全表スキャンは、インデックスが大幅にデータ検索の速度を加速することができる場所と順番に関与列でインデックス付けと考えるべきである避けるべきです。
2.適切なSQLを使用して説明し、適切な深さの分析を行うことができます。
3. LIMIT 1た場合にデータの一行。
インデックスフィールドを使用しての条件として4、インデックスは複合インデックスであるならば、あなたはそれ以外の場合はインデックスが使用されません、システムがインデックスを使用して確実にするための条件として、最初のフィールドにインデックスを使用し、すべきでなければなりませんそのフィールドの順序は、順序インデックスと一致しているので、可能な限り。
5. WHERE句内の関数、算術演算、またはその他の式を実行しない「=」左、またはシステムが適切に索引付け動作しない可能性があります。
6.クエリの効率を向上させることができる指標をカバーする適切な時間を採用しています。
最後に書かれました：
最後に、コードワードが見ることは容易ではない、それは懸念の聖歌のポイントがあるだけでなく、収集ポイントは、いじめを懸念しています！