Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 View и производительность  [new]
Testor1
Member

Откуда:
Сообщений: 679
Всем привет!

Вопрос к спецам.

На сколько правильно отдельные части сложных запросов (Join-ов) прятать во view? Замедляют ли они запросы на их основе?
16 май 13, 16:07    [14306452]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Glory
Member

Откуда:
Сообщений: 104751
Testor1
На сколько правильно отдельные части сложных запросов (Join-ов) прятать во view? Замедляют ли они запросы на их основе?

View - это просто текст запроса, который хранится на сервере.
Как место хранения текста запроса может влиять на скорость выполнения запроса ?
16 май 13, 16:08    [14306469]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
На сколько правильно отдельные части сложных запросов (Join-ов) прятать во view? Замедляют ли они запросы на их основе?

View - это просто текст запроса, который хранится на сервере.
Как место хранения текста запроса может влиять на скорость выполнения запроса ?



К примеру запрос 1 работал быстрее чем запрос 2 при одинаковых WHERE и больших таблицах

Glory - не спорю с вами, прочто что можете сказать из своего опыта. Есть влияние или нюансы которые надо учитывать ?

--Запрос 1 
SELECT * 
FROM TABLE1 t1 INNER JOIN TABLE2 t2 ON t1.id = t2.t1_id 
                       INNER JOIN TABLE3 t3 ON t2.id = t3.t2_id 


--  Запрос 2
SELECT * 
FROM VIEW1 v1 INNER JOIN TABLE3 t3 ON v1.id = t3.t2_id 


CREATE VIEW VIEW1 AS 
SELECT * 
FROM TABLE1 t1 INNER JOIN TABLE2 t2 ON t1.id = t2.t1_id 
16 май 13, 16:25    [14306660]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Glory
Member

Откуда:
Сообщений: 104751
Testor1
К примеру запрос 1 работал быстрее чем запрос 2 при одинаковых WHERE и больших таблицах

Вы что думаете, что сервер сначала выполняет Запрос 1, потом Запрос 2, а только потом начинает соединять результаты ??
16 май 13, 16:26    [14306666]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
Testor1,

Все VIEW перед созданием плана раскрываются в запросе,
после чего результат оптимизируется.
16 май 13, 16:26    [14306673]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Testor1
Member

Откуда:
Сообщений: 679
iap
Testor1,

Все VIEW перед созданием плана раскрываются в запросе,
после чего результат оптимизируется.


Можно считать VIEW неким аналогом WITH() AS() ?
16 май 13, 16:30    [14306703]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
К примеру запрос 1 работал быстрее чем запрос 2 при одинаковых WHERE и больших таблицах

Вы что думаете, что сервер сначала выполняет Запрос 1, потом Запрос 2, а только потом начинает соединять результаты ??


Нет, но полагал, что ненужные столбцы в VIEW могут повлиять на производительность запроса.

То есть view с тремя столбцами в селекте отработает быстрее чем view с 10 столбцами из которых будут использоваться только три.
При условии что VIEW сам состоит из нескольких джойнов
16 май 13, 16:32    [14306726]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Glory
Member

Откуда:
Сообщений: 104751
Testor1
Нет, но полагал, что ненужные столбцы в VIEW могут повлиять на производительность запроса.

Это потому, что вы по прежнему думаете, что VIEW есть нечто больше, чем текст запроса.

Testor1
То есть view с тремя столбцами в селекте отработает быстрее чем view с 10 столбцами из которых будут использоваться только три.

view не отрабатывает. view предоставляет оптимизатору текст своего запроса
16 май 13, 16:36    [14306758]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
Нет, но полагал, что ненужные столбцы в VIEW могут повлиять на производительность запроса.

Это потому, что вы по прежнему думаете, что VIEW есть нечто больше, чем текст запроса.

Testor1
То есть view с тремя столбцами в селекте отработает быстрее чем view с 10 столбцами из которых будут использоваться только три.

view не отрабатывает. view предоставляет оптимизатору текст своего запроса


Правильно ли я понимаю

SELECT *
FROM VIEW1 v1 INNER JOIN TABLE3 t3 ON v1.id = t3.t2_id

Что если я добавлю условие проверки по одному из столбцов view1, то оптимизатор сделает такой же план запроса, как если бы вместо view был бы исходный селект ?
16 май 13, 16:54    [14306915]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
Нет, но полагал, что ненужные столбцы в VIEW могут повлиять на производительность запроса.

Это потому, что вы по прежнему думаете, что VIEW есть нечто больше, чем текст запроса.

Testor1
То есть view с тремя столбцами в селекте отработает быстрее чем view с 10 столбцами из которых будут использоваться только три.

view не отрабатывает. view предоставляет оптимизатору текст своего запроса


И еще влияет ли на производительность выборка всех столбцов - *?

CREATE VIEW AS view_tes
SELECT *
FROM t1 inner join t2 on t1.col1 = t2.col1
16 май 13, 16:56    [14306933]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Glory
Member

Откуда:
Сообщений: 104751
Testor1
Что если я добавлю условие проверки по одному из столбцов view1, то оптимизатор сделает такой же план запроса, как если бы вместо view был бы исходный селект ?

Не путайте красное и соленое.
Если вы части сложного запроса спрячите во view-ы, то план "упрощенного" запроса будет таким же
А если вы поменяете какую-то часть запроса, то и план может измениться
16 май 13, 16:57    [14306942]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Glory
Member

Откуда:
Сообщений: 104751
Testor1
И еще влияет ли на производительность выборка всех столбцов - *?

CREATE VIEW AS view_tes
SELECT *
FROM t1 inner join t2 on t1.col1 = t2.col1

Какого запроса то ?
Еще раз - CREATE VIEW _не выполняет_ никакого запроса
16 май 13, 16:58    [14306954]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
И еще влияет ли на производительность выборка всех столбцов - *?

CREATE VIEW AS view_tes
SELECT *
FROM t1 inner join t2 on t1.col1 = t2.col1

Какого запроса то ?
Еще раз - CREATE VIEW _не выполняет_ никакого запроса


Попробую на практике использовать VIEW.

Вложенность view так же не влияет на производительность ?
16 май 13, 17:08    [14307038]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Glory
Member

Откуда:
Сообщений: 104751
Testor1
Вложенность view так же не влияет на производительность ?

Вот вы сейчас знаете, что спрашиваете ?
Вы спрашиваете - а если я напишу огромный запрос со множеством таблиц, то отразится ли это на производительности.
16 май 13, 17:10    [14307052]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
iap
Member

Откуда: Москва
Сообщений: 47142
Но есть особые случаи - индексированные VIEW, секционированные VIEW и т.п.
Надеюсь, здесь спрашивают не о них
16 май 13, 17:12    [14307068]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
Вложенность view так же не влияет на производительность ?

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


Да. Понимаю, что чем больше таблиц в запросе, тем сложнее будет запрос и сложнее оптимизатору построить корректный план запроса.

В голове застряло, что view замедляет ... и не могу от этого сразу отойти.

Запросы у меня большие. Множество справочников надо связывать с историческими данными, и плюс еще делать делать фильтрацию.

Пытаюсь понять как правильно реализовывать код
16 май 13, 17:17    [14307095]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Владимир Затуливетер
Member

Откуда:
Сообщений: 427
Testor1
В голове застряло, что view замедляет ... и не могу от этого сразу отойти.

Если написать одну большую и сложную вьюху и использовать ее везде, даже когда например нужно выбрать данные только из одной двух таблиц, то тогда планы запросов с вьюхой и без могут быть разными и их производительность соответственно тоже...
16 май 13, 17:40    [14307259]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Владимир Затуливетер, можно писать вью со 100 таблицами, но при этом запрос из неё будет брать только из одной-двух.
Т.е. вьюхи тоже надо писать правильно.
См. правило LEFT JOIN + ключ, идентичность типов и наличие FK и других ограничений (UNION + CK).

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

А ещё существуют параметризованные вью.
16 май 13, 23:44    [14308780]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Но вот когда делается UPDATE view, да на которой висит триггер ...
16 май 13, 23:48    [14308788]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Glory
Testor1
На сколько правильно отдельные части сложных запросов (Join-ов) прятать во view? Замедляют ли они запросы на их основе?

View - это просто текст запроса, который хранится на сервере.
Как место хранения текста запроса может влиять на скорость выполнения запроса ?



Indexed views are stored in the database in the same format as a table. The query processor treats indexed views the same way it treats base tables.

Only the source of a nonindexed view is stored. The query optimizer incorporates the logic from the view source into the execution plan it builds for the SQL statement that references the nonindexed view.
17 май 13, 10:10    [14309610]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Т.е вышеприведенное утверждение только половина правды.
17 май 13, 10:10    [14309612]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Glory
Member

Откуда:
Сообщений: 104751
Cammomile
Indexed views are stored in the database in the same format as a table.

Какой молодец
Заодно опубликуйте и условия, которые должен соблюдать view, чтобы стать индексированным

И еще не забудьте это
In SQL Server Enterprise, the query optimizer automatically considers the indexed view. To use an indexed view in all other editions, the NOEXPAND table hint must be used.
17 май 13, 10:13    [14309624]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
Я просто отметил, что не всегда вью это просто текст запроса.
17 май 13, 10:29    [14309755]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
Glory
Member

Откуда:
Сообщений: 104751
Cammomile
Я просто отметил, что не всегда вью это просто текст запроса.

Т.е. обсуждение не читал, просто увидел фразу и решил прокомментировать ?
17 май 13, 10:30    [14309775]     Ответить | Цитировать Сообщить модератору
 Re: View и производительность  [new]
LSV
Member [заблокирован]

Откуда: Киев
Сообщений: 30817
Если Вью содержит сложные вычисления, то применение вью может быть медленным, т.к. оптимизатор может протупить и сначала вычислить всю вьюху, а потом взять из неё пару строк.
У меня была такая ситуация: вьюха состояла из двух вьюх, каждая из которых имела сложное вычисление внутри.
При этом запрос с этой вьюхой иногда некисло и непредсказуемо тупил.
Переделал тож самое без вьюхи - тупёж исчез.
17 май 13, 11:28    [14310255]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить