id による並べ替え datetime で注文する際にクラスター化インデックス スキャンを使用する可能性があります ソートまたはインデックス ルックアップのいずれかを使用します。
これらの方法はどちらも、クラスター化されたインデックス スキャンよりも低速です。
テーブルが id によってクラスター化されている場合 、基本的には既にソートされていることを意味します。レコードは B+Tree に含まれています id のページをリンクするリンク リストがあります。 注文。エンジンは、リンクされたリストをトラバースして、id で並べ替えられたレコードを取得する必要があります。 .
id の場合 s が順番に挿入されました。これは、行の物理的な順序が論理的な順序と一致し、クラスター化インデックス スキャンがさらに高速になることを意味します。
レコードを datetime で並べたい場合 、2 つのオプションがあります:
- テーブルからすべてのレコードを取得し、並べ替えます。遅さは明らかです。
datetimeでインデックスを使用する .インデックスはディスクの別の領域に格納されます。これは、エンジンがネストされたループでインデックス ページとテーブル ページの間を行き来する必要があることを意味します。さらに遅いです。
順序を改善するために、datetime に個別のカバリング インデックスを作成できます。 :
CREATE INDEX ix_mytable_datetime ON mytable (datetime) INCLUDE (field1, field2, …)
、クエリで使用するすべての列をそのインデックスに含めます。
このインデックスは、テーブルのシャドウ コピーのようなものですが、データの並べ替え順序が異なります。
これにより、datetime による順序付けを行うキー ルックアップを取り除くことができます (インデックスにはすべてのデータが含まれているため)。 id と同じ速さ .
更新:
この問題に関する新しいブログ投稿: