Хранилище данных SQL Azure — медленное левое соединение с временной таблицей

Я запускаю очень простой запрос (см. ниже) в своем «Хранилище данных SQL Azure», и это занимает 5 секунд. Если я запускаю тот же запрос в «Azure SQL Server», это занимает 0 секунд, что кажется более нормальным. (Этот запрос, по сути, представляет собой набор ЛЕВЫХ СОЕДИНЕНИЙ без условий, как вы увидите из плана выполнения, если запустите его.)

Как это возможно, что это занимает 5 секунд?

CREATE TABLE #output(
  val INT
 )

INSERT INTO #output VALUES (1)

SELECT 
 (SELECT val FROM #output),
 (SELECT val FROM #output),
 (SELECT val FROM #output),
 (SELECT val FROM #output),
 (SELECT val FROM #output),
 (SELECT val FROM #output),
 (SELECT val FROM #output),
 (SELECT val FROM #output)

person Lars    schedule 07.12.2015    source источник
comment
Извините, я все еще озадачен тем, что здесь происходит   -  person Tom Page    schedule 07.12.2015
comment
Пробовали ли вы ОБНОВИТЬ СТАТИСТИКУ #output Если разные механизмы SQL работают по-разному, это предполагает, что они используют разные планы запросов. Обновление статистики во временной таблице может значительно улучшить выбранный план. Я знаю, что SQL Server предполагает наличие только одной записи, но версия хранилища данных может не   -  person Tom Page    schedule 07.12.2015
comment
В #output вставлена ​​только 1 запись. И, как я уже упоминал, на Azure SQL Server это не займет много времени. (Я запустил это в цикле, чтобы увидеть величину разницы, и то, что заняло 45 минут в SQLDW, заняло 4 секунды в SQL Server. Таким образом, разница ОГРОМНА).   -  person Lars    schedule 07.12.2015
comment
Я также обновил статистику с помощью CREATE STATISTICS stats_col1 на #output (val), но это не имеет значения   -  person Lars    schedule 07.12.2015


Ответы (1)


Предложение для хранилища данных SQL Azure — это двузначные терабайты данных и миллиарды строк. Это то, для чего он в основном предназначен, поэтому вы вполне можете обнаружить, что с некоторыми меньшими запросами, определенными шаблонами запросов и меньшими базами данных они просто не будут работать, точно так же, как вы обнаружите, что загрузка 30 ТБ в базу данных SQL PaaS не будет выполняться. либо. В этих случаях вам нужно переосмыслить свои запросы и действительно ли вы хотите запускать эти запросы там. Например, в этом случае простое преобразование в виде запроса UNION обеспечило производительность в доли секунды в моем хранилище данных SQL Azure, например

SELECT val FROM #output
UNION ALL
SELECT val FROM #output
UNION ALL
SELECT val FROM #output
UNION ALL
SELECT val FROM #output
UNION ALL
SELECT val FROM #output
UNION ALL
SELECT val FROM #output
UNION ALL
SELECT val FROM #output
UNION ALL
SELECT val FROM #output


SELECT *
FROM
    (
    SELECT 'a' s, val FROM #output
    UNION ALL
    SELECT 'b' s, val FROM #output
    UNION ALL
    SELECT 'c' s, val FROM #output
    UNION ALL
    SELECT 'd' s, val FROM #output
    UNION ALL
    SELECT 'e' s, val FROM #output
    UNION ALL
    SELECT 'f' s, val FROM #output
    UNION ALL
    SELECT 'g' s, val FROM #output
    UNION ALL
    SELECT 'h' s, val FROM #output
    ) x
PIVOT ( MAX(val) FOR s In ( [a], [b], [c], [d], [e], [f], [g], [h] ) ) pvt


-- Use CTAS to materialise the pivot view if required
CREATE TABLE #output2
WITH
(
    DISTRIBUTION = ROUND_ROBIN,
    LOCATION = USER_DB,
    HEAP
)
AS
SELECT *
FROM
    (
    SELECT 'a' s, val FROM #output
    UNION ALL
    SELECT 'b' s, val FROM #output
    UNION ALL
    SELECT 'c' s, val FROM #output
    UNION ALL
    SELECT 'd' s, val FROM #output
    UNION ALL
    SELECT 'e' s, val FROM #output
    UNION ALL
    SELECT 'f' s, val FROM #output
    UNION ALL
    SELECT 'g' s, val FROM #output
    UNION ALL
    SELECT 'h' s, val FROM #output
    ) x
PIVOT ( MAX(val) FOR s In ( [a], [b], [c], [d], [e], [f], [g], [h] ) ) pvt

Если вам действительно нужны строки как столбцы, вы всегда можете использовать PIVOT. Недавно у меня была аналогичная проблема при создании таблицы больших чисел. В исходном запросе использовался цикл, который, как правило, является плохой практикой, но он выполняется за несколько секунд на ванильном SQL Server и является одноразовой операцией. Производительность в хранилище данных SQL Azure была ужасной, поэтому я просто выполнил запрос на своем локальном экземпляре, скопировал данные с помощью bcp и через несколько минут отправил их в хранилище. (Я также искал более основанный на наборах способ создания таблицы чисел:)

Мы также рассматривали возможность использования Change Data Capture (CDC), которая еще недоступна в складской версии продукта, поэтому мы рассмотрели возможность размещения промежуточной области в базовом SQL Server, задействование CDC в этих таблицах и передачу их в хранилище через Функции SSIS и CDC. С тех пор мы отвергли это, но вы поняли идею; если у вас есть подлинные запросы, которые вам нужно выполнить, но вы не рассматриваете возможность их перезаписи или даже рассматриваете возможность использования обычной версии SQL Server на виртуальной машине, а затем передачу ее в хранилище, например, через SSIS, Polybase и т. д.

ХТН

(Это, вероятно, следует переместить на dba.stackexchange.com)

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

SELECT val, val, val, val, val, val, val
FROM #output

Я немного покопался в этом и обнаружил, что если вы подключены к базе данных master, то этот запрос выполняется хорошо и быстро. Вы не можете использовать оператор USE для изменения контекста базы данных в хранилище данных SQL Azure, но если вы были подключены через какой-либо клиент (например, SSIS, sqlcmd), это может быть обходным путем. Я по-прежнему придерживаюсь своего первоначального утверждения о том, что некоторые шаблоны запросов с малым объемом не особенно подходят для этой версии продукта. Я также смотрел на ключевое слово EXPLAIN, которое дает своего рода план запроса, чтобы вы могли получить представление о том, что происходит под капотом, но это уже другая история...

person wBob    schedule 09.12.2015