Awkward JOIN вызывает низкую производительность

Question

У меня есть хранимая процедура, которая объединяет данные из нескольких таблиц через UNION ALL. Если параметры, переданные в хранимую процедуру, не применяются к конкретной таблице, я пытаюсь «закоротить» эту таблицу, используя «вспомогательные биты», например. @DataSomeTableExists и добавление соответствующего условия в предложение WHERE, например.

Стол для одного (psuedo) в хранимой процедуре немного неудобен и вызывает у меня некоторое горе.

DECLARE @DataSomeTableExists BIT = (SELECT CASE WHEN EXISTS(SELECT * FROM #T WHERE StorageTable = 'DATA_SomeTable') THEN 1 ELSE 0 END); 
... 

UNION ALL 

SELECT * 
FROM REF_MinuteDimension AS dim WITH (NOLOCK) 
CROSS JOIN (SELECT * FROM #T WHERE StorageTable = 'DATA_SomeTable') AS T  
CROSS APPLY dbo.fGetLastValueFromSomeTable(T.ParentId, dim.TimeStamp) dpp 
WHERE @DataSomeTableExists = 1 AND dim.TimeStamp >= @StartDateTime AND dim.TimeStamp <= @EndDateTime 

UNION ALL 

... 

Примечание: REF_MinuteDimension не более чем smalldatetimes с шагом в минуту.

(1) План выполнения (ниже) указывает на предупреждение оператора вложенных циклов, говорящего, что предиката соединения нет. Это, вероятно, не очень хорошо, но между таблицами действительно нет естественного соединения. Есть ли лучший способ написать такой запрос? Для каждого ParentId в T я хочу получить значение из UDF за каждую минуту между @StartDateTime и @EndDateTime.

(2) Даже когда @DataSomeTableExists = 0, в этом запросе есть активность ввода-вывода, как сообщается SET STATISTICS IO ON, и фактический план выполнения. В плане выполнения указано 14,2% стоимости, что слишком сильно, учитывая, что эти таблицы даже не применяются в этом случае.

SELECT * FROM #T WHERE StorageTable = 'DATA_SomeTable' возвращается пустым.

Это так, как мой запрос написан? Почему бы не вспомогательный бит или пустое Т короткое замыкание этого запроса?

Answer 1

Для 2) Я могу с уверенностью сказать, что линию

CROSS JOIN (SELECT * FROM #T WHERE StorageTable = 'DATA_SomeTable') AS T 

Ill силы #T проанализировать и ввести объединение. Вы можете создавать версии SP с этим соединением и без него и использовать этот флаг для выполнения того или другого, но я не могу сказать, что я плохо знаю время отклика || cpu clocks || I/O bandwith || memory.

Для 1) Я предлагаю удалить (nolock), если вы используете SQL Server 2005 или лучше, и внимательно следить за этим UDF. Не могу сказать больше без хорошей скрипты SQL.

Answer 2

Я должен упомянуть, у меня есть no clue, если это когда-нибудь будет работать, так как это нечетный способ написать sproc и табличные UDF, которые не понятны оптимизатору запросов. Возможно, вам придется построить свой набор результатов в табличной переменной или временной таблице условно, на основе операторов IF, а затем вернуть эти данные. Но я хотел бы попробовать это, во-первых:

--helper bit declared 
declare @DataSomeTableExists BIT = 0x0 
if exists (select 1 from #T where StorageTable = 'DATA_SomeTable') 
begin 
    set @DataSomeTableExists = 0x1 
end 

... 

UNION ALL 

SELECT * 
FROM REF_MinuteDimension AS dim WITH (NOLOCK) 
CROSS JOIN (SELECT * FROM #T WHERE StorageTable = 'DATA_SomeTable' and @DataSomeTableExists = 0x1) AS T 
CROSS APPLY dbo.fGetLastValueFromSomeTable(T.ParentId, dim.TimeStamp) dpp 
WHERE @DataSomeTableExists = 0x1 AND dim.TimeStamp >= @StartDateTime AND dim.TimeStamp <= @EndDateTime 

UNION ALL 

... 

А если вы уже не знаете, UDF может быть давая вам странные показания в планах выполнения. Я не знаю достаточно, чтобы дать вам точные данные, но вы должны искать вокруг, чтобы понять ограничения.

Answer 3

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

Есть минусы динамического SQL, так read up