1
インデックス列の非常に大きなテーブルからのSELECT TOP 1は非常に遅いですが、逆順ではありません（「desc」）
強力なサーバーでSQL Server 2014を実行している約1 TBの大規模データベースがあります。数年はすべてうまくいきました。約2週間前に、次のような完全なメンテナンスを行いました。すべてのソフトウェアアップデートをインストールします。すべてのインデックスを再構築し、DBファイルを圧縮します。ただし、実際の負荷が同じ場合、特定の段階でDBのCPU使用率が100％から150％増加するとは予想していませんでした。 多くのトラブルシューティングを行った後、非常に単純なクエリに絞り込みましたが、解決策が見つかりませんでした。クエリは非常に簡単です。 select top 1 EventID from EventLog with (nolock) order by EventID 常に約1.5秒かかります！ただし、「desc」を使用した同様のクエリには常に約0ミリ秒かかります。 select top 1 EventID from EventLog with (nolock) order by EventID desc PTableには約5億行があります。データ型がbigint（Identity列）EventIDのプライマリクラスター化インデックス列（ordered ASC）です。上部のテーブルにデータを挿入する複数のスレッド（より大きなEventID）があり、下部からデータを削除する1つのスレッド（より小さなEventID）があります。 SMSSでは、2つのクエリが常に同じ実行プランを使用することを確認しました。 クラスター化インデックススキャン。 推定および実際の行番号は両方とも1です。 推定および実際の実行回数は両方とも1です。 推定I / Oコストは8500です（高いようです） 連続して実行した場合、クエリコストは両方で同じ50％です。 インデックス統計を更新しましたがwith fullscan、問題は続きました。インデックスを再構築しましたが、問題は半日消えたようですが、戻ってきました。 IO統計をオンにしました： set statistics io on 次に、2つのクエリを連続して実行し、次の情報を見つけました。 （最初のクエリについては、遅いクエリ） テーブル「PTable」。スキャンカウント1、論理読み取り407670、物理読み取り0、先読み読み取り0、lob論理読み取り0、lob物理読み取り0、lob先読み読み取り0。 （2番目のクエリ、高速クエリの場合） …