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, …