タグ付けされた質問 「paging」

2
数百万行にわたるカスタマイズ可能な並べ替えによるページングパフォーマンス
このアプリケーションには、ユーザーが多数のレコード(1000万から2000万)をページングできるグリッドがあります。グリッドは、多数の列(20以上)での昇順と降順の並べ替えをサポートしています。値の多くも一意ではないため、アプリケーションはidブレイクとしてidでソートして、行が常に同じページに表示されるようにします。例として、ユーザーがウィジェットサイズ(最大から開始)でソートする場合、アプリケーションは次のようなクエリを生成します。 SELECT TOP 30 * -- (Pretend that there is a list of columns here) FROM Test -- WHERE widgetSize > 100 ORDER BY widgetSize DESC, id ASC このクエリは(キャッシュデータを使用して)実行に約15秒かかります。主なコストは、widgetSizeで約130万行をソートすることです。このクエリを調整しようとしてWHERE、最大のWidgetSizesに制限された句を追加すると(上記のクエリでコメントアウトされている)、クエリはわずか〜800msかかることを発見しました(上位50,000の結果はすべてウィジェットサイズ> 100です) 。 WHERE句のないクエリが非常に遅いのはなぜですか?widgetSize列の統計情報を確認したところ、上位739行のWidgetSize> 506が示されています。30行しか必要ないため、SQLサーバーはこの情報を使用してウィジェットサイズの行のみを並べ替える必要があることを推測できませんどっちが大きい? 私はこのことができますことを知っている特定の上のインデックスに追加することにより、迅速に実行したクエリwidgetSizeとはid、しかし、このインデックスは、この特定のシナリオでのみ有用であり、(例えば)ユーザがソート方向を反転させる場合は無価値になります。このテーブルには多くの追加の列が含まれており、各インデックスは大きいため(〜200 MB)、すべての可能な並べ替え順序にインデックスを追加する余裕はありません。 すべての可能な並べ替え順序にインデックスを追加せずにこれらのクエリクエリを実行する方法はありますか?(ユーザーは20以上の列のいずれかでソートできます) 次のスクリプトは、上記のテーブルを作成し、代表的なデータを入力します。テーブルは実際のテーブルよりもはるかに狭いですが、私が見ているパフォーマンスを示しています。私のPCでは、where句のあるクエリは200ミリ秒かかりますが、where caluseのないクエリは800ミリ秒かかります。 警告:このスクリプトの実行後の結果のデータベースのサイズは最大2Gbです。 CREATE TABLE Test ( id INT NOT NULL IDENTITY(1,1) PRIMARY KEY, …

3
SQL Serverのページネーション
約100 GBの非常に大きなデータベースがあります。私はクエリを実行しています: select * from <table_name>; 100行目から200行目だけを表示したいです。 これが内部でどのように起こるかを理解したいです。データベースは、ディスクからすべてのレコードをメモリにフェッチし、100番目から400番目の行をクエリクライアントに送り返しますか?または、Bツリーなどのインデックス作成メカニズムを使用して、データベースからそれらのレコード(100番目から200番目)のみを取得するメカニズムが存在しますか? これはページネーションの概念に関連していることがわかりましたが、データベースレベルで内部的にどのように発生するかを正確に見つけることができませんでした。

2
タイムスタンプに基づくウィンドウオフセット
ソーシャルフィードの結果をページングするために使用するクエリを書いています。コンセプトは、モバイルアプリがN個のアイテムをリクエストし、@CutoffTime以下で呼び出した開始日時を提供することです。カットオフ時間の目的は、ページングウィンドウをいつ開始するかを確立することです。行オフセットの代わりにタイムスタンプを使用している理由は、新しいソーシャルコンテンツが追加された場合でも、古い投稿を取得するときに、一貫した場所からタイムスタンプを使用できるようにするためです。 ソーシャルフィードアイテムは自分または友達からのものである可能性があるUNIONため、これら2つのグループの結果を組み合わせるためにa を使用しています。もともと私はTheQuery_CTEなしでロジックを試しました、UNIONそしてそれは遅い犬でした。 これは私がやったことです(関連するテーブルスキーマを含む): CREATE TABLE [Content].[Photo] ( [PhotoId] INT NOT NULL PRIMARY KEY IDENTITY (1, 1), [Key] UNIQUEIDENTIFIER NOT NULL DEFAULT NEWID(), [FullResolutionUrl] NVARCHAR(255) NOT NULL, [Description] NVARCHAR(255) NULL, [Created] DATETIME2(2) NOT NULL DEFAULT SYSUTCDATETIME(), ); CREATE TABLE [Content].[UserPhotoAssociation] ( [PhotoId] INT NOT NULL, [UserId] INT NOT NULL, [ShowInSocialFeed] …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.