Однако факт что транзакции  в виниле не спасают от илдов внутри

так а прчием тут транзакция?

Теоретически, транзакция может привести к тому, что данные не успеют вытесниться из кэша, пока не будут прочитаны, и илдов фактически не будет. Но я не уверен, что это работает на практике

в случае уникального индекса select не отличается от get
в случае неуникального индекса — select может возвращать несколько записей, get не работает

т.о. для работы с уникальными индексами рекомендуется использовать get, т.к. он даёт 100% предсказуемый результат — 1 тапл
для неуникальных индексов с select нужно быть аккуратным (может неожиданно вернуть много данных, если не указать лимит. ну и не пользоваться offset, т.к. сложность O(N)). лучше использовать pairs вместо select

как сказал Алексей — транзакции нужны для модификации: они меняют поведение yield'ящих операций, таких как insert/update/replace/...

В случае винила всё совсем по другому, и надеюсь, что у вас не винил :)

ну тут ситуация, когда точно известно, какие именно записи вернет селект, и есть их primary ключи. поэтому встал выбор, забирать их селектом или пачкой гетов по одной. А что с винилом ужасного?)

у вас sql что ли? или как вы select in планируете делать?

в случае уникального ключа select так же, как и get, вернёт ровно 1 ключ

у меня tnt, просто перед этим запросом забираются данные в другом месте, но с теми же ключами

в тарантуле выборку нескольких полных первичных ключей нельзя выполнить за 1 селект если что

то есть схема такая:
1)забрали в инстансе1 через select(request) пачку записей
2)надо забрать в инстансе2 пачку записей с теми же айди, что и у предыдущих. можно сделать такой же селект, как в (1), с тем же запросом, и получить те же айди. а можно сделать много гет запросов по известным из (1) ключам

так там в (1) запрос самый обычный, типа id<1000

а селективность какая?

не совсем понял вопрос

т е вы сравниваете селект допустим на 1к записей со сколькими гетами?

а. тут заранее неизвестно

ну если гетами делать, то соответственно в виде хранимки, которая получает пачку ключей и возвращает пачку записей, во избежание сети

ну это понятно

но в целом ответ меняется в зависимости от этого

с точки зрения доступа к данным -- да, с точки зрения интерфейса не совсем:

tarantool> #box.space.test:select({nil})
---
- 100
...

tarantool> #box.space.test:get({nil})
---
- error: Invalid key part count in an exact match (expected 1, got 0)
...

можно случайно передать nil из-за ошибки в приложении, тогда выгоднее использовать именно get, потому что он рейзит ошибку вместо фуллскана

то есть если брать пример с id<1000, то при малом количестве результатов оптимальнее гет, при большом селект?