MySQL百万級改ページ最適化（Mysql千万級快速改ページ）

以下のポイントを共有します。私の経験はSQLの勉強を始めたばかりの時に、このように

 
SELECT * FROM table ORDER BY id LIMIT 1000, 10; 

と書いていますが、データが百万級に達した時には、このように書くと

 
SELECT * FROM table ORDER BY id LIMIT 1000000, 10; 

が遅くなるかもしれません。数十秒でネット上で多くの最適化方法が必要です。これは完璧です。

 
SELECT * FROM table WHERE id >= (SELECT id FROM table LIMIT 1000000, 1) LIMIT 10; 

は上記の文よりも5～10倍早いです。また、IDが連続していない部分を調べるためには、IDを探してから、クエリフィールドの長い文字列をinクエリー

 
SELECT * FROM table WHERE id BETWEEN 1000000 AND 1000010; 

で共有するのが一番いい方法です。テーブル設計時には、このフィールドにフィールドを追加します。文字列を直接調べないでください。効率が低いので、この文字列のcrc 32またはmd 5を調べて、Mysql千万級の高速改ページLimit 1,111データをどうやって最適化しますか？By:jack Mysql limitページの遅い解決方法（Mysql limit最適化、百万から千万までの記録が速い改ページを実現します）MySql性能はどれぐらい高いですか？phpを使って半年以上経って、本当にこのように深く考えたのは昨日からです。苦しみと絶望があったことがあります。今まで自信を持っています。MySqlというデータベースは绝対にdba级の达人に适しています。普通は少し1万件のニュースをする小型システムはどう书いてもいいです。xxフレームで快速开発ができます。しかし、データ量は10万から100万から千万までです。彼の性能はまだそんなに高いですか？ちょっとしたミスで、システム全体が書き換えられ、さらに本システムが正常に動作しないかもしれません。もういいです。無駄話はもうたくさんしません。実際に話して、例を見てください。データテーブルcollect（id、title、info、vtype）はこの4つのフィールドに対して、titleは定長、infoはtext、idは次第に、vtypeはinyint、vtypeはインデックスです。これは基本的なニュースシステムの簡単なモデルである。今は中にデータを詰めて、10万編のニュースを詰めます。最後のcollectは10万本の記録で、データベーステーブルはハードディスクの1.6 Gを占有します。OK、次のsql文を見てください。select id、title from collect limit 1000,10；とても速いです基本的に0.01秒でOKです。次のselect id、title from collect limit 90000,10を見てください。9万本から改ページして、結果は？8-9秒で完成しますが、my godはどこに問題がありますか？実はこのデータを最適化して、ネットで答えを見つけます。次の文を見てください。select id from collect order by id limit 90000,10；速くて、0.04秒でOKです。なぜですか？idキーを使ったのでインデックスを作るのは当然早いです。オンラインの変更方法は、select id、title from collect where id=(select id from collect order by id limit 90000,1)limit 10です。これはidを使ったインデックスの結果です。しかし問題は複雑で、それぐらいで終わりです。次の文を見てください。select id from collect where vtype=1 order by id limit 90000,10;遅くなりました。8-9秒を使いました。ここに来たら、多くの人が私と同じように、崩壊感があると信じています。vtypeはインデックスを作りましたか？どうして遅くなりますか？vtypeがインデックスを作ったのはいいです。直接select id from collect where vtype=1 limit 1000,10;速いです。基本的に0.05秒ですが、90倍になります。9万からです。0.05*90=4.5秒のスピードです。とテスト結果は8～9秒で一桁になりました。ここから分表の考えを提出する人がいますが、これはdis cuzフォーラムと同じ考えです。考え方は次の通りです。インデックス表を作ります。t（id、title、vtype）を定めて、ページを分けて、ページを分けて結果を出してから、collectの中にinfoを探しに行きます。実行してもいいですか？実験してみれば分かります。10万本がt（id、title、vtype）に記録され、データテーブルのサイズは20 Mぐらいです。select id from t where vtype=1 order by id limitで90000,10;もうすぐです。基本的に0.1-0.2秒で走りきれます。どうしてですか？私はcollectのデータが多すぎて、ページ別に長い道を走ると思います。limitはデータテーブルのサイズと全く関係があります。実はこのようにしますか？それとも全表スキャンです。データ量が小さいので、10万しかないです。OK、狂気の実験をして、100万本を加えて、性能をテストします。10倍のデータを入れたら、すぐにt表は200 m以上になります。それとも先ほどの検索文ですか？時間は0.1-0.2秒で終わります。デモンストレーションの性能は大丈夫ですか？違う！私たちのlimitはまだ9万ですから、早いです。大きいのをください。90万からselect id from t where vtype=1 order by id limit 90000,10;結果を見てください。時間は1～2秒です。why分表した時間はまだこんなに長くて、とても憂鬱です。長いとlimitの性能が上がるかもしれません。最初は一つの記録の長さが固定されていますから、mysqlは90万の位置を計算できるはずです。しかし、私達はmysqlの知能を過大評価しました。彼はビジネスデータベースではありません。だから、discuzは100万本の記録に到達すると遅くなると言われています。これは本当だと信じています。これはデータベースの設計と関係があります。まさかMySQLは100万の制限を突破できないですか？100万ページで本当に限界ですか？答えは：NO！！！なぜ100万を突破できないかというと、mysqlのデザインができないからです。ここでは非分表法を紹介します。狂気のテストをします。一枚の表は100万の記録を作りました。そして、10 Gのデータベースはどのように速くページを分けますか？はい、私達のテストはまたcollect表に戻ります。30万のデータは分表法で実行できます。30万を超える彼のスピードは遅いです。耐えられません。もちろん分表＋私という方法を使うなら、絶対完璧です。しかし、私のこの方法を使ったら、メーターなしで完璧に解決できます。複合インデックス！ある時mysqlインデックスを設計した時、インデックスの名前を見つけたら、何個のフィールドを選んで入れますか？最初のselect id from collect order by id limit 90000,10；こんなに速くインデックスを外したからですが、whereを入れたらインデックスを離れません。試してみるとsearch（vtype、id）というインデックスが付けられています。そしてselect id from collect where vtype=1 limit 90000,10をテストします。とても速いです0.04秒で完成再テスト：select id、title from collect where vtype=1 limit 90000,10；非常に残念です。8-9秒でsearchインデックスが出ませんでした。再テスト：search（id，vtype）は、まだselect idという語句で、非常に残念です。0.5秒です。以上のことから、where条件がある場合、またlimitを引用したい場合は、インデックスを設計し、whereを第一位に置く必要があります。limit用のキーは第二位に置いて、しかもselectのメインキーしかないです。ページの問題を完璧に解決しました。IDに素早く戻ることができます。limitの最適化を期待しています。このようなロジックで100万レベルのlimitは0.0x秒で終わります。mysql文の最適化とインデックス化はとても重要です。さて、原題に戻りましたが、どうやって上記の研究を開発に迅速に応用することができますか？複合で調べたら、私のライト級のフレームは役に立ちません。改ページの文字列は自分で書かなければならないですが、どれぐらい面倒ですか？ここでもう一つの例を見ると、構想が出てきます。select*from collect where id in(9000,12,50,7000)；なんと0秒で調べきれます。mygod、mysqlのインデックスはなんとin文に対しても同じ効果があります。オンラインでインデックスが使えないと言っているのは間違いです。この結論があれば、軽量フレームに簡単に適用できます。コードは以下の通りです。

 
SELECT * FROM table WHERE id IN(10000, 100000, 1000000...); 

は簡単に変換します。実は簡単な考え方です。2）2回目の検索結果。小さな索引+ほんの少しの変化はmysqlに百万または千万級の高効率なページをサポートすることができます！ここの例を通して、大型システムに対して、PHPはフレームワーク、特にsql文すら見えないフレームを使ってはいけません。最初はライト級のフレームが崩れそうだったからです。小型アプリケーションだけに適した高速開発では、ERP、OA、大型サイトに対して、データ層に論理層が含まれているものはフレームワークが使えません。プログラマがsql文に対するコントロールを失ったら、プロジェクトのリスクは幾何級数的に増加します。特にmysqlを使う時は、mysqlは専門のdbaが必要です。彼の最高性能を発揮できます。インデックスによる性能差は千倍以上かもしれません。PS：実際のテストを経て、100万のデータ、160万のデータ、15 Gの表、190 Mのインデックス、インデックスを歩いても、limitは0.49秒です。だから、他の人を譲らないほうがいいです。