лукап выполняет запрос к источнику для каждой записи в потоке . Запрос в память быстр, к дисковому кешу медленнее. Некешированный лукап самый медленный, зато ему не нужна предварительная загрузка данных. Join двух SQ требует их одинаковой сортировки - если она уже выполнена, то соединение работает быстро.
Если можно, как это будет на конкретном примере:
Есть внешний запрос, где выбираются поля, в т.ч. подселектами:
1.
2.
3.
4.
5.
select
...
<subselect к табличке sub_tab, содержащей 500 000 строк>
... (и другие подзапросы)
from main_tab
main_tab содержит 2 000 000 строк.
Таблицы связаны по полю ID в соотношении 1:1
Подзапрос, сам-по-себе, берёт только 5 записей по всем своим ограничениям. Это для 2-х миллионов строк основного.
В маппинге:
есть SQ по main_tab, берущий 2 млн. строк - основная выборка, содержащая поля, к которым нужно добавить поля выбранные такими подселектами.
Как в этом случае поведёт себя:
1) кэшированный
2) и некэшированный лукап
3) и если запрос сразу поместить в Sql Query в SQ ?
1) Если мы добавляем кэшированным лукапом этот подзапрос - он просто кэширует 5 строк (как понял). Потом, подставляя условие связи с основной выборкой, добавляет поле, заполняя его для этих 5-ти ID данными и всё - очень быстро.
2) Если лукап не кэшируется, то он будет таскать из базы все 2 000 000 по одной. А потом упадёт в обморок узнав, что нужно только 5.
3) Если делать не через лукап, а через ещё одно SQ (взяв нужное поле и ID, для связи с основной выборкой), то, как я понял, разница в том, что не будет бегать туда сюда а выберет все 2 млн. на стороне БД. Это конечно не_медленно (БД работает быстро), но, дольше, чем лукапом из кэша, и грузит базу. А потом сортировка и Join поля к основной выборке ещё потребуют времени.
Поэтому здесь лучше кашированный лукап. я так понял.
Между моим и Вашим пониманием - немалый пробел, поэтому мне немного сложновато понять так. Может быть, на таком примере будет проще, если у Вас есть время.
