Производительность Inline-TVF против просмотров

9

У меня есть база данных, где я использую встроенные TVF (функции табличных значений) вместо представлений. Например, у меня могут быть две таблицы, называемые [модель автомобиля] и [производитель автомобиля], которые я объединяю в TVF [fnCarBrands].

Эти TVF затем вызываются другими TVF для дальнейшей обработки и создания отчетов. Поэтому я мог бы взять свою функцию [fnCarBrands] и присоединиться к таблице [Год покупки], чтобы сформировать функцию [fnCarBrandHistory]. И так далее для нескольких слоев TVF.

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

Как производительность встроенных TVF, написанных таким образом, соотносится с представлениями?

sql-server-2005 performance view functions Кулак ярости
источник
Скорее всего, вы увидите те же планы выполнения и ту же производительность.
AK
это то, что я думал, но мне сказали, что TVF действует как скобка в алгебре - это заставляет механизм БД выполнить этот запрос в первую очередь перед оптимизацией. Как мне сказали, использование представлений позволяет оптимизатору оптимизировать весь запрос как единое целое.
FistOfFury
Что-то вроде примечания, но есть идея, почему вместо просмотра использовались TVF? Просто код-обезьяна против подхода данных-обезьяны к проблеме?
Марк Стори-Смит
@ MarkStorey-Smith, да, причина в том, как вы говорите, код-обезьяна против подхода обезьян-данных.
FistOfFury

Ответы:

12

Оптимизатор запросов обрабатывает встроенную табличную функцию как представление:

CREATE FUNCTION dbo.InlineUdf(@arg1 int)
RETURNS TABLE
AS
RETURN 
(
    ... your query here ...
);

Стол-функция мульти-оператор управляет более , как хранимые процедуры. Обычно они должны выполняться несколько раз, а не складываться в основной запрос:

CREATE FUNCTION dbo.MultiStatementUdf (@col1 int)
RETURNS @result TABLE 
(
    id int primary key NOT NULL,
    ... 
)
AS
BEGIN
   DECLARE @var1 int
   set @var1 = 42

   INSERT @result
   SELECT ...
   RETURN
END;
Andomar
источник
1
@ Я понимаю, что TVF с несколькими утверждениями работают как черный ящик, движок не знает, что в нем, и не может оптимизировать запрос. Есть ли у вас какие-либо статьи, на которые вы можете сослаться, в которых говорится, что представления и встроенные TVF эквивалентны?
FistOfFury
4

Вам нужно будет создать аналогичные представления для функций и запросить каждое из них, глядя на план выполнения, чтобы увидеть, что происходит с каждым из них.

mrdenny
источник
Точно. Бенчмаркинг, наблюдение за собой - это единственный надежный способ обучения.
AK
@mrdenny Нет ли способа предсказать, как оптимизатор будет обрабатывать каждый тип запроса? Конечно, есть некоторые правила, которым он следует.
FistOfFury
2
@FistOfFury Да, существуют правила, тысячи за тысячами, дополненные сотнями лет эвристического кода для разработчиков. Вот почему вам придется протестировать или попросить у Microsoft исходный код оптимизатора.
Марк Стори-Смит
Если вы хотите лучше понять, как ядро ​​базы данных определяет, что делать, вам нужно ознакомиться с внутренними документами SQL Server, amazon.com/s/…
HLGEM
3

Конечно, создание представлений, которые вызывают другие представления, также снижает производительность. Не идите по этому маршруту. Пишите запросы, которые вам нужны, и не используйте ни TVF, ни представления, если вы хотите повысить производительность. Это является наслоение , что создает проблемы, это почти всегда плохо делать при запросе базы данных , и вы можете быстро закончить ударять предел количества таблиц вы можете ссылаться тоже, тем более , что вы часто в конечном итоге ссылки на одни и те же таблицы в разных слоях. Кроме того, хотя кажется, что его легче поддерживать, это не так. Попробуйте отладить или добавить столбец из-за нового требования, когда слой, который нужно исправить, находится внизу.

HLGEM
источник