ascとdescの両方向にインデックスを作成する

過去数週間、私は古いFirebirdデータベースに対して激怒しています。このデータベースはさまざまな理由でひどいですが、私が気付いたことの1つは、すべてのテーブルのすべてのフィールドに2つのインデックスがあることです。それぞれに単一のセグメントがあり、1つはasc順番に、もう1つはdesc順番に。

同じインデックスセグメントを持つ2つのインデックスを有することに単一セグメントのインデックスのいずれかの利点があるが、1で-以外のすべてのテーブル内のすべてのフィールドのインデックスを持つのwtf'nessから、それは考えて私を得たdescと1でasc？何か得られることはありますか、または最新のDBMSは単純にascインデックスを使用し、最後から始めて、必要に応じて逆方向に動作しますか？

逆順のインデックススキャンを実行できない最新のデータベースを聞いて驚いたでしょう。

• SQL Serverは確かに実行し、逆方向スキャンは実行プランに示されます。
• Firebird（ページテキストで後方検索）。
• MySQL

Firebirdインデックスは理論的には双方向ですが、ページの書き込み順序が原因で逆方向が信頼できないため、エンジンは実際には双方向性を使用しません。逆方向の読み取りでは、新しく追加されたページではなく、古いインデックスページをまだ指しているリンクを読み取って、インデックスエントリをスキップすることがあります。これは、Firebird for Database Expert：Episode 3-On Disk Consistencyで説明されています。

したがって、インデックスの双方向性は保証されないため、Firebirdは宣言された方向（昇順または降順）のインデックスのみを読み取ります。データベースにこれらすべてのインデックスがある理由については、データベースを設計している人が何をしているのかわからなかったか、またはこれらのインデックスを追加すると列のソートが速くなると思いました。

はい、降順のインデックスを使用しない場合、大きなテーブルで顕著なパフォーマンスヒット（FB 2.5）があります。

select first 1 * 
from mytable 
where pk_id >= 200000 
order by pk_id desc

このクエリは、主キーフィールド "pk_id"（整数）の値に基づいて、前のレコードを見つけるために使用されます。