Чи оптимізовано перегляди, коли я додаю до них пункт WHERE?


28

Чи має значення, якщо ви фільтруєте Погляд всередині або поза ним?

Наприклад, чи є різниця між цими двома запитами?

SELECT Id
FROM MyTable
WHERE SomeColumn = 1

Або

SELECT Id
FROM MyView
WHERE SomeColumn = 1

І MyViewвизначається як

SELECT Id, SomeColumn
FROM MyTable

І чи відрізняється відповідь, якщо таблиця-джерело розташована на пов'язаному сервері?

Я запитую, бо мені потрібно двічі запитувати велику таблицю (44mil рядків) на пов'язаному сервері, і отримати сукупність результатів. Мені хочеться знати, чи слід створити два представлення для доступу до даних, по одному для кожного запиту, або чи можу я піти з одного перегляду та WHEREпункту.


1
чому б ви навіть використовували подання, якщо у вас є лише одна таблиця?
HLGEM

3
@HLGEM безпека?
JNK

2
@HLGEM Перегляд фактично містить кілька запитів до декількох баз даних на різних серверах, і він об'єднує їх усі UNION ALL. Набагато простіше використовувати View, ніж потрібно переписувати запит UNION, коли мені потрібні дані.
Рейчел


1
@datagod Я маю це на увазі, дякую :) У цьому випадку є досить невелике додаток, яке збирає дані з кучки серверів, виконує деякі розрахунки та виписує купу звітів. У нього є своя база даних, тому що деякі підрахунки досить ресурсомісткі, і я хотів відокремити її від усього іншого.
Рейчел

Відповіді:


12

Ви не повинні бачити абсолютно ніякої різниці у планах чи ефективності між цими двома варіантами. Коли вигляд запитується, він розширюється на запит проти базової таблиці, що означає, що буде використано те саме пошук або сканування.

Тепер, залежно від типу даних та селективності MyColumn, якщо ви хочете створити відфільтрований індекс на базовій таблиці (коли ви переходите на SQL Server 2008+), ви можете отримати кращу ефективність, але це знову не буде відрізнятися через перегляд або без.


3
Що щодо цього питання , яке задається питанням, чому запит із whereпунктом поза переглядом займає набагато більше часу, ніж коли він розміщений у поданні?
Рейчел

1
Якщо перегляди не для продуктивності, вони просто для структури?
profimedica

1
@profimedica індексуються уявлення можуть бути створені для підвищення продуктивності (наприклад , для зберігання проміжних результатів , як наповнювачі замість розрахунку їх під час виконання). Якщо подання не матеріалізується, це може бути з різних причин: DRY (загальне з'єднання або фільтр, що виконується в багатьох різних запитах), безпека, затуманення, спрощення схеми.
Аарон Бертран

5

Ось лише короткий приклад, який показує, що різниці не повинно бути. База даних - це AdventureWorksбаза даних.

Два визначення:

create view Person.vContactWhere
as

    select *
    from person.Contact
    where ContactID = 24

go

create view Person.vContactNoWhere
as

    select *
    from person.Contact

go

Тут буде перший запит, із WHEREпунктом, включеним у визначення перегляду:

select *
from person.vContactWhere

Ось план виконання:

введіть тут опис зображення

І другий запит, з WHEREпунктом не у визначенні перегляду, а в SELECTзапиті:

select *
from person.vContactNoWhere
where ContactID = 24

Ось такий план виконання:

введіть тут опис зображення

Як видно з цих планів виконання, вони однакові з однаковими результатами. Я не знаю ситуації, коли такий тип логіки / дизайну може призвести до різних результатів. Тож я хотів би сказати, що ви в будь-якому випадку безпечні, і йдіть з особистими уподобаннями (або з магазинами).


1
Що щодо цього питання , яке задається питанням, чому запит із whereпунктом поза переглядом займає набагато більше часу, ніж коли він розміщений у поданні?
Рейчел

1
@Rachel Я думаю, що gbn досить добре пояснив це у своєму дописі та статті, на яку він вказував. Я не знаю, як ще це зробити.
Томас Стрінгер

Я пов’язав це, тому що в цьому випадку плани виконання не були однаковими, що відрізняється від того, що говорить ваша відповідь.
Рейчел

1
@Rachel Проблема в цьому прикладі відсутнє правило перетворення . Це стосується не лише представлень даних, але й CTE та інших виразів таблиць. У загальному випадку недопустимо натискання присудка на вирази таблиці, що містять функції ранжування, оскільки це змінить результат. Причина, яка є дійсною в цьому випадку, полягає в тому, що Whereстаття підходить до PARTITION BY. SQL Server 2008, схоже, має нове правило SelOnSeqPrjдля визнання цього конкретного випадку.
Мартін Сміт


2

На основі того, що я читаю , SQL використовуватиме стандартний вид, як підзапит, при визначенні плану виконання.

Тож використовуючи мій приклад запиту,

SELECT Id
FROM MyView
WHERE SomeColumn = 1

де MyViewвизначено як

SELECT Id, SomeColumn
FROM MyTable

він повинен генерувати той самий план виконання, що і

SELECT Id
FROM 
(
    SELECT Id, SomeColumn
    FROM MyTable
) as T
WHERE SomeColumn = 1

але цей план виконання може відрізнятися від того, що було б створено

SELECT Id
FROM MyTable
WHERE SomeColumn = 1

Я не впевнений, чи відповів би ця відповідь для індексованих переглядів


Я не думаю, що це явна заміна тексту.
Аарон Бертран

@AaronBertrand Ви можете мати рацію. Я, чесно кажучи, поняття не маю ... Я навчаюсь, як іду :) Це припущення грунтувалося на інших речах, які я читав про те, як погляди схожі на макроси. Я трохи відредагував питання, щоб вказати, що я маю на увазі стандартні перегляди, а не індексовані подання.
Рейчел

@Rachel - Заміна відбувається з алгебризованим деревом не на текстовому рівні.
Мартін Сміт

@MartinSmith Hrrmm це не те, що я сказав? Що плани виконання повинні бути однаковими, а не щоб текст був однаковим? Я не впевнений, що розумію "алгебризоване дерево"
Рейчел

Щойно у відповідь на ваш коментар до самого запитання, в якому сказано, що він "вставляє текст Погляду у ваш запит" та коментар Аарона вище. Деякі відомості про етапи розбору / складання тут . Насправді у вашій відповіді також згадується підміна тексту. Чи є це відмінністю, яке варто зробити. Не впевнений! Але я думаю, це пояснює, для чого sp_refreshviewпотрібна концепція підстановки тексту.
Мартін Сміт
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.