Ariochне знал...
значит на курсах у меня ты не был. :-)
более того, список номеров записей перед вытаскиванием записей еще и сортируется, чтобы чтение было упорядочено по страницам данных, а не по ключам. Иначе io будет в десятки раз выше. Как например, при "навигации по индексу".
http://ibaseforum.ru/viewtopic.php?f=4&t=4175

hvladБаг подтверждаю,
баг-то в чем? волшебное значение столбца, для которого может быть создано N ключей (больше 1) в уникальном индексе?

Ariochа вот сейчас карта большой таблицы каааак вылезет за пределы оперативки отпущенной серверу
к примеру, таблица с 2 760 304 951 записей, занимает 249 гиг. Индекс (их много) по одному столбцу, в зависимости от распределения значений - в среднем 100 гиг (от 63 до 122).
Но если в качестве "битовой карты" даже использовать просто массив номеров записей, то Record_count * 8 = 21 гиг. Да, может не влезть. Но как-то никто пока не жаловался. :-)
А для настоящей битовой карты будет Record_count / 8, то есть 329 мб.

Ariochс неверсионными индексами в целом разумно
при чем тут "неверсионные" индексы? речь про выборку записей по найденным в индексе их номерам. Хоть с версиями, хоть без, надо сначала номера записей из ключей выбрать. А потом уже можно или по этим номерам записей ехать по data pages, или "склеивать" такие массивы номеров как битовые, при and/or и прочем.
Некоторые сервера могут выдавать данные и без обращения к таблице, это уже "индексное покрытие", другая тема. Вот в ней уже "неверсионность" индекса является определяющей.

p.s. по поводу ключей с номерами транзакций.

28.10.2014 [Firebird-devel] Indexes - things to think about for V
3) Transaction IDs in index keys

Someone mentioned including transaction ids in the index key to avoid reading record data when using an index that provides all needed
information. Those situations are real - count of customers in Mexico, junction records for M to M relationships, etc. In some cases, two
transaction ids are required - one for the transaction that created entry and the transaction superseded it. That's potentially 16 bytes subtracted from the key size. OK, maybe not so big a problem, but it also means that when a key changes, the change must be made in two places. But you know all those arguments.

Jim's going to hate this. Might it be possible to have a second sort of index specifically for those cases where the read efficiency outweighs the storage and management overhead? Yes, one more place where the application designer can be blamed for poor performance.

короче, полная шляпа.