SSIS Lookup Transform использовать таблицу или запрос - PullRequest
2 голосов
/ 20 мая 2019

У меня есть преобразование «Уточняющий запрос» для таблицы с 30 столбцами, но я использую только два столбца: столбец ID для соединения и столбец «Обновление» в качестве выходных данных.

При подключении я должен ввести запрос Select ID, Update From T1 или Использовать таблицу в раскрывающемся списке?

Использование таблицы в выпадающем меню будет похоже на Select * From T1 или SSIS достаточно умен, чтобы знать, что мне нужны только 2 столбца.

Я думаю, мне следует пойти с Запросом Select ID, Update From T1.

Ответы [ 2 ]

1 голос
/ 21 мая 2019

Если вам нужны только два столбца из таблицы поиска, тогда лучше использовать запрос выбора, чем выбирать таблицу из выпадающего списка, но указанные столбцы должны содержать первичный ключ (ID). Потому что чтение всех столбцов потребляет больше ресурсов. Даже если это может не иметь значимого эффекта в небольших таблицах.

Для получения дополнительной информации вы можете обратиться к следующему ответу в сообществе администраторов баз данных:


Обратите внимание, что то, что @JWeezy упомянул о поиске по большой таблице, верно. Поиски не предназначены для больших таблиц, вместо них я буду использовать SQL JOIN.

1 голос
/ 20 мая 2019

На соединении я должен ввести запрос Выберите ID, Обновить с T1 или Использовать таблицу в раскрывающемся списке?

Лучше всего указать, какие столбцы вы хотите.

Используя таблицу в выпадающем меню, это будет похоже на выполнение Select * From T1

Да, это SELECT *.

или SSIS достаточно умен, чтобы знать, что мне нужны только 2 столбца?

Нет.

Имейте в виду, что поиски хороши для извлечения данных из таблиц измерений, где количество строк и набор записей невелики. Если вы имеете дело с большими объемами уникальных данных, лучше выполнить MERGE JOIN. Разница в производительности может быть существенной. Например, при использовании функции «Уточняющий запрос» для строк данных по 20 КБ время выполнения может составлять десятки минут. Однако MERGE JOIN будет выполняться в течение нескольких секунд.

Недостатки поиска в том, что они ведут себя как коррелированные подзапросы: они запускают запрос к серверу для каждой проходящей через него строки. Вы можете иметь кеш поиска данных, что означает, что SSIS сохранит результаты в памяти, а затем проверит память, прежде чем идти на сервер для всех последующих строк, проходящих через поиск. В результате это эффективно только в том случае, если имеется большое количество совпадающих записей для небольшого набора кеша. Другими словами, поиск не является оптимальным, когда для поиска требуется большое количество идентификаторов. К этому моменту кэширование данных практически бессмысленно.

Здесь вы бы переключились на использование MERGE JOIN. Примечание: вам нужно выполнить SORT для обоих потоков данных до MERGE JOIN, потому что компонент MERGE JOIN требует сортировки входящих строк.

При неправильном обращении один плохо размещенный «Уточняющий запрос» может поставить на колени целый пакет - поиск может стать огромным препятствием для производительности. Хотя при правильном обращении поиск может упростить проектирование потока данных и ускорить разработку, удалив дополнительную разработку, необходимую для потоков данных MERGE JOIN.

Суть всего этого в том, что вы хотите, чтобы Lookup выполнял наименьшее количество запросов к серверу.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...