Выполнение параллельного запроса Transact SQL - PullRequest
0 голосов
/ 23 ноября 2011

Предположим, у меня есть

INSERT INTO @tmp1 (ID) SELECT ID FROM Table1 WHERE Name = 'A'
INSERT INTO @tmp2 (ID) SELECT ID FROM Table2 WHERE Name = 'B'
SELECT ID FROM @tmp1 UNION ALL SELECT ID FROM @tmp3

Я хотел бы выполнить запросы 1 и 2 параллельно, а затем объединить результаты после их завершения.

Есть ли способ сделать это в чистом T-SQL или способ проверить, будет ли он делать это автоматически?

Предыстория для тех, кто хочет этого: я исследую сложный поиск, в котором есть несколько условий, которые позже объединяются (термин ИЛИ (термин 2 И термин 3) ИЛИ термин 4 И пункт 5 = термин 5), и поэтому я исследую, будет ли это полезно выполнять эти - в основном несвязанные - условия параллельно, а затем объединять результирующие таблицы (и вычислять ранги, веса и т. д.).

например. должно быть несколько наборов результатов:

SELECT COUNT(*) @tmp1 union @tmp3
SELECT ID from (@tmp1 union @tmp2) WHERE ...
SELECT * from TABLE3 where ID IN (SELECT ID FROM @tmp1 union @tmp2)
SELECT * from TABLE4 where ID IN (SELECT ID FROM @tmp1 union @tmp2)

Ответы [ 3 ]

3 голосов
/ 23 ноября 2011

Ты не.SQL не работает так: он не процедурный.Это приводит к состязаниям и проблемам с данными из-за других соединений

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

В любом случае все, что вам нужно, - это, если только вы не дали нам плохой пример:

SELECT ID FROM Table1 WHERE Name = 'A'
UNION
SELECT ID FROM Table2 WHERE Name = 'B'

Я подозреваю, что вы думаете о "параллельной работе" из-за этого процедурного мышления.Какова ваша фактическая желаемая проблема и цель?

Примечание: переменные таблицы не допускают параллельные операции: Могут ли запросы, которые читают переменные таблицы, генерировать планы параллельного выполнения в SQL Server 2008?

2 голосов
/ 23 ноября 2011

Вы не решаете, что распараллеливать - оптимизатор SQL Server делает. И самая большая единица работы, с которой оптимизатор будет работать, - это один оператор, поэтому вы найдете способ выразить свой запрос как один оператор , а затем положитесь на SQL Server, чтобы выполнить свою работу, что обычно это будет хорошо.

Если, построив ваш запрос, производительность не приемлема, вы можете посмотреть на применение подсказок или навязывание определенных планов. Многие люди разбивают свои запросы на несколько операторов, либо полагая, что они могут выполнять работу лучше, чем SQL Server, либо потому, что они «естественно» думают о поставленной задаче. Оба являются «неправильными» (для определенных значений неправильными), но если есть естественная разбивка, вы можете скопировать ее с помощью выражений Common Table - это позволит вам назвать каждую часть проблемы, а затем объединить их вместе, все как часть одного заявления.

например:.

;WITH TabA AS (
     SELECT ID FROM Table1 WHERE Name = 'A'
), TabB AS (
     SELECT ID FROM Table2 WHERE Name = 'B'
)
SELECT ID FROM TabA UNION ALL SELECT ID FROM TabB

И это позволит серверу решить, как наилучшим образом разрешить этот запрос (например, решить, сохранять ли промежуточные результаты в «временных» таблицах)


Видя в одном из ваших других комментариев, что вы обсуждали необходимость «работать с» промежуточными результатами - это все еще можно сделать с помощью CTE (если это не просто случай, когда вы не в состоянии выразить «конечный» результат) как один запрос), например:

;WITH TabA AS (
   SELECT ID FROM Table1 WHERE Name = 'A'
), TabAWithCalcs AS (
   SELECT ID,(ID*5+6) as ModID from TabA
)
SELECT * FROM TabAWithCalcs
1 голос
/ 23 ноября 2011

Почему бы просто:

SELECT ID FROM Table1 WHERE Name = 'A'
UNION ALL
SELECT ID FROM Table2 WHERE Name = 'B'

, тогда, если SQL Server захочет запустить два выбора параллельно, он сделает это со своим собственным нарушением.

В противном случае нам нужно больше контекста для того, чего вы пытаетесь достичь, если это не практично.

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