序文
データベースクエリのテーブルからのレコードの数万人の必要性は、すべて1回のクエリの結果は非常に遅くなります場合は、データの増加量は特に明らかで、特にして、あなたは、ページングクエリを使用する必要があります。データベースクエリのページでは、多くの方法および最適化のポイントがあります。私の知っている方法のいくつかについて、以下簡単に。
準備
試験のために下記の数を最適化するために、テーブルを有し、以下に説明します。
-
表名：order_history
-
説明：事業の受注履歴テーブル
-
メインフィールド：unsigned int型ID、TINYINT（4）int型
-
フィールド：表の37項目の合計、および他の大きなテキストデータが含まれていないが、VARCHAR（500）まで、IDフィールドはインデックスであり、そしてインクリメントされます。
-
データ容量：5709294
-
MySQLのバージョン：5.7.16
百万テストテーブルの行を検索しようとすると、自分自身をテストする必要がある場合は、あなたが挿入されているどのようなデータをテストするためにシェルスクリプトを書くことができ、容易ではありません。
すべての次のSQL文の実行環境は変化しなかった、次は、基本的なテストの結果、次のとおりです。
SELECT COUNT（*）ORDERS_HISTORYから。
戻る：5709294
3件の問い合わせ時間は以下の通りでした。
8903のms8323 ms8401 MS
一般的なページングクエリ
シンプルな制限句を使用して、一般的なページングクエリを達成することができます。文の次の句を制限します：
テーブルLIMIT SELECT * FROM列[、オフセット] | 行がオフセットOFFSET
LIMIT句はSELECTステートメントによって返されるレコードの数を指定するために使用することができます。次の点に注意してください。
-
最初のパラメータは、返される最初のオフセットの行を指定します
-
2番目のパラメータは、返される行の最大数を指定します
-
引数を1つしか与えられている場合：これは、返される行の最大数を表し
-
-1の2番目のパラメータは、すべての行の末尾にレコードのセットからオフセット取得します
-
0は最初の行（の代わりに、1）であるオフセット
以下では、アプリケーションの例です。
ORDERS_HISTORYから*を選択してここでタイプ= 8限界1000,10。
第10条のステートメントは、それが記事10010データへの記事1001で、テーブルORDERS_HISTORYから最初の1000個のデータの後にデータを照会します。
上記のデフォルトに対応するマスターキー（通常はID）ソート結果を使用して、データテーブルのレコード：
ORDERS_HISTORYから*を選択する場合、ID制限10000,10によってタイプ= 8ため、
3件の問い合わせ時間は以下の通りでした。
3040のms3063 ms3018 MS
このクエリに応答して、時間の次のテストのクエリインパクトレコード量：
ORDERS_HISTORYから*を選択してここでタイプ= 8限界10000,1。ORDERS_HISTORYから*を選択してここでタイプ= 8限界10000,10。ORDERS_HISTORYここでタイプ= 8制限10000,100 SELECT * FROM。ORDERS_HISTORYから*を選択してここでタイプ= 8限界10000,1000。ORDERS_HISTORYから*を選択してここでタイプ= 8限界10000,10000。
次の3つのクエリの時間は以下のとおりです。
クエリレコード：3072msの3092msの3002msは10のレコード照会：3118ms 3200ms 3128msクエリ1000の記録：3412msの3468ms 3394ms万のクエリレコード：3749msの3802msの3696ms 3081ms 3077ms 3032msをクエリが100を記録
私はまた、より多くのは、それがあまりにもかかる時間の問い合わせ記録量として12回のクエリ、ビューの点から、クエリ時間は、100未満のクエリレコード量の時点で、ほぼ確実に、基本的に差はないクエリ時間を、やりましたより多くの。
お問い合わせは、テストをオフセット：
ここで、タイプ= 8限界100,100 ORDERS_HISTORY SELECT * FROM。ORDERS_HISTORYから*を選択してここでタイプ= 8限界1000,100。ORDERS_HISTORYここでタイプ= 8制限10000,100 SELECT * FROM。ORDERS_HISTORYここでタイプ= 8制限100000,100 SELECT * FROM。ORDERS_HISTORYから*を選択してここでタイプ= 8限界1000000,100。
次の3つのクエリの時間は以下のとおりです。
25msの24msの24msクエリ千オフセット：100クエリをオフセット78msの76msの77msを10000クエリをオフセット：3092ms 3212ms 3128msクエリ100 000オフセット：3878ms 3812ms 3798msクエリ1,000,000オフセット：14608ms 14062ms 14700ms
クエリの増加で相殺された後、特にクエリがオフセット100,000を超える、クエリ時間の急激な増加です。
このページングクエリはデータベースから最初のレコードのスキャンを開始しますので、より多くの後方に、より遅いクエリの速度が、より多くのデータのクエリは、クエリが全体の速度が遅くなります。
サブクエリの最適化の使用
このように第一位置決めIDは、後で問い合わせをオフセット位置、及び、この方法は、ID増分の場合にも適用可能です。
ORDERS_HISTORYから*を選択してここでタイプ= 8限界100000,1。ここで、タイプ= 8限界100000,1 ORDERS_HISTORYからIDを選択します。ORDERS_HISTORY SELECT * FROMここタイプ= 8、ID> = 100を制限する（タイプ= 8制限は100000,1 ORDERS_HISTORYからIDを選択）。ORDERS_HISTORYここでタイプ= 8制限100000,100 SELECT * FROM。
次のようにクエリ時間4文は次のとおりです。
最初の文：3674ms番目のステートメント：1315ms第3条のステートメント：1327msステートメント第4条：3710ms
上記のクエリのためのことに注意してください：
-
最初の文と第二文の比較：選択*速度を使用して選択し、IDの代わりには3倍に増加しました
-
比較条2及び3声明：数十ミリ秒の速度差
-
第3条及び第4条文文の比較：増加の速度からID恩恵を選択し、3倍に増加し、第3条のステートメントのクエリの速度
オリジナルの一般的なクエリーの方法に比べてこのように速く、数回になります。
Idは、最適化を使用して定義しました
これは継続的に増加しているデータテーブルのidは、その後、我々はページとクエリクエリの数、あなたが間のIDを使用することができますし、照会するレコードの数に基づいてクエリの範囲のIDを計算できることを前提としています。
1000000および1000100限界100との間のORDERS_HISTORYここタイプ= 2、ID SELECT * FROM。
問合せ時間：15msのが12msののて9ms
大幅に検索速度を最適化することができます。このクエリは、実質的に数十ミリ秒以内に完了することができます。使用する唯一の制限は、IDの状況を明確に認識しているが、タイムテーブル作成のほとんどは、ページングクエリのために利便性の多くをもたらした基本的なidフィールドを追加します。
また、書き込みの別の種類があるかもしれません。
ORDERS_HISTORY SELECT * FROMここID> = 1000001限界100。
もちろん、関連するマルチテーブルのクエリは、クエリするIDテーブルクエリの他のセットを使用する場合、このアプローチがしばしば使用され、照会する方法で使用することができます。
ID（ここで、商品= 'ペン' trade_2からORDER_ID選択）には、100を制限ORDERS_HISTORY SELECT * FROM。
このように、クエリは注意する：いくつかのMySQLのバージョンは、IN句での制限の使用をサポートしていません。
一時テーブルの使用を最適化
それは、最適化を照会するために属していないこのように、ここでの方法来ます。
質問IDは最適化を定義したために、あなたは、このような時に使用履歴テーブルとして、idが連続的に増加するが、いくつかのシナリオでされて必要がある、またはIDページングを記録するために一時記憶テーブルを使用することを検討して、データの問題が欠落したときに登場し、クエリでページングを使用するためのID。これは、大幅にデータの数千万の場合は特に量、伝統的なページングクエリの速度を向上させることができます。
データテーブルのID説明
通常の状況下では、IDフィールドを追加することを余儀なくデータベース内のテーブルの確立がので問い合わせを容易にするために、各テーブルにインクリメントされます。
そのような注文や他の非常に大規模なデータベースのようなデータの量は、一般に、サブライブラリーサブテーブルになる場合。この時間は、一意の識別子IDデータベースとして推奨されていないが、固有IDを生成するために、分散型発電機の高い並行性を使用する必要があり、データテーブル内の追加フィールドを使用することは、固有の識別子を格納します。
最初の使用範囲クエリ位置決めID（またはインデックス）を使用し、その後数回クエリの速度を向上させることができるデータを見つけるためにインデックスを使用します。つまり、最初のIDを選択し、*選択しています。