ascとdescの両方向にインデックスを作成する
過去数週間、私は古いFirebirdデータベースに対して激怒しています。このデータベースはあらゆる種類の理由でひどいですが、私が気付いた1つのことは、every single field of every single tableに2つのインデックスがあることです。それぞれに単一のセグメントがあり、1つはasc順、もう1つはdesc順です。
すべてのテーブルのすべてのフィールドにインデックスを付けることのwtf性は別として、単一セグメントインデックスには、同じインデックスセグメントを持つ2つのインデックスがあるがdescに1つあるという利点があると思いました。 ascに1つありますか？何か得られることはありますか、または最近のDBMSはascインデックスを単純に使用し、最後から始めて、必要に応じて逆方向に動作しますか？
逆順のインデックススキャンを実行できない最新のデータベースを聞いて驚いたでしょう。
- SQL Serverは確かに実行し、 逆方向スキャンは実行プランに示されます です。
- Firebird （ページテキストの後方を検索）。
- MySQL
Firebirdインデックスは理論的には双方向ですが、ページの書き込み順序のために逆方向は信頼できないため、エンジンは実際には双方向性を使用しません。逆方向の読み取りでは、新しく追加されたページではなく、古いインデックスページをまだ指しているリンクを読み取って、インデックスエントリをスキップする可能性があります。これは データベースエキスパート向けのFirebird：エピソード3-ディスクの整合性 で説明されています。
したがって、インデックスの双方向性は保証されないため、Firebirdは宣言された方向（昇順または降順）のインデックスのみを読み取ります。データベースにこれらすべてのインデックスがある理由については、データベースを設計している人が何をしているのかわからなかったか、またはこれらのインデックスを追加すると列のソートが速くなると思いました。
はい、降順インデックスを使用しない場合、大きなテーブルで顕著なパフォーマンスヒット（FB 2.5）があります。
select first 1 *
from mytable
where pk_id >= 200000
order by pk_id desc
このクエリは、主キーフィールド "pk_id"（整数）の値に基づいて、前のレコードを見つけるために使用されます。