それは、考えれば考えるほど理解できる、奇妙な曲線を持っているように見えるものの 1 つです。もちろん、ある程度は。そして、それは私にはまったく意味がありません。
教えてくれませんか?
それは、考えれば考えるほど理解できる、奇妙な曲線を持っているように見えるものの 1 つです。もちろん、ある程度は。そして、それは私にはまったく意味がありません。
教えてくれませんか?
ほとんどの場合、最初に結果を並べ替える必要があるためです。たとえば、Google で検索すると、最大 100 ページの結果しか表示できません。特定のキーワード (またはキーワードの組み合わせ) について、1000 を超える Web サイトをページランクで並べ替える必要はありません。
ページネーションは高速です。ソートが遅い。
Lubosの言うとおりです。問題は、ページングを行っていること (ネットワークから大量のデータを取得すること) ではなく、ページで実際に何が行われているのかを把握する必要があることです..
ページングする必要があるという事実は、大量のデータがあることを意味します。大量のデータはソートに時間がかかります:)
この質問はかなりよくカバーされているように見えますが、多くの人を捕まえるので、MySQL 固有のものを少し追加します。
の使用は避けてくださいSQL_CALC_FOUND_ROWS
。データセットが些細なものでない限り、2 つの別々のクエリで一致をカウントし、x 個の一致を取得する方がはるかに高速になります。(些細な場合は、どちらの方法でもほとんど違いに気付かないでしょう。)
これは本当に漠然とした質問です。問題をよりよく理解するには、具体的な例が必要です。
私はあなたが印刷されたページのページ付けを意味していると思っていました-それは私が歯を切ったところです. ページのすべてのコンテンツの収集、ポジショニング (ここでは膨大な数のルール、制約エンジンが非常に役立ちます)、正当化についての素晴らしい独白を始めるつもりでした... しかし、どうやらあなたは Web ページ上の情報を整理するプロセスについて話していたようです。 .
そのために、私はデータベースのヒットを推測します。ディスク アクセスが遅い。メモリに入れたら、並べ替えは簡単です。
もちろん、ランダムクエリでの並べ替えには時間がかかりますが、同じページ付けされたクエリが定期的に使用されることに問題がある場合は、データベースの設定に問題があります(不適切なインデックス作成/まったくなし、メモリが少なすぎるなど。 mはdb-managerではありません)またはページ付けを深刻に間違って行っています:
ひどく間違っている:たとえばselect * from hugetable where somecondition;
、array.lengthを使用してページ数を取得する配列を実行して、関連するインデックスを選択し、配列をダイカードします。次に、ページごとにこれを繰り返します...これは私が深刻に間違っていると呼んでいます。
より良い解決策は、2つのクエリです。1つはカウントだけを取得し、もう1つはとを使用して結果を取得しlimit
ますoffset
。(一部のプロプライエタリな非標準SQLサーバーには1つのクエリオプションがあるかもしれません、私は知りません)
悪い解決策は、実際には小さなテーブルで問題なく機能する可能性があります(実際、2つのクエリを作成するオーバーヘッドは、1つのクエリですべての行を取得するよりも大きいため、非常に小さなテーブルで高速になることは考えられません。そう...)しかし、データベースが大きくなり始めるとすぐに問題が明らかになります。