Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 3741
Есть запрос типа такого, прибольшом количестве записей (> 1млн) работает не быстро и вызывает блокировки.
Можно ли как-то по-другому извернуться, чтобы ускорить?

SELECT t1_id, t2_name, t3_int, t4_text, t5_value
FROM t1 
  LEFT OUTER JOIN t2 ON (t2_id = t1_id) 
  LEFT OUTER JOIN t3 ON (t3_id = t1_id) 
  LEFT OUTER JOIN t4 ON (t4_id = t1_id)
  LEFT OUTER JOIN t5 ON (t5_id = t1_id)
1 дек 16, 14:43    [19955667]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
Ролг Хупин,

нам нужен план(с)
1 дек 16, 14:46    [19955692]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
iap
Member

Откуда: Москва
Сообщений: 47000
Ролг Хупин,

выбираются все данные из таблиц без всяких ограничений?
1 дек 16, 14:47    [19955698]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
aleks2
Guest
Дык... ежели тащить на клиента "> 1млн" записей - оно всегда будет "небыстро".

Хоть из шкуры вылези.
1 дек 16, 14:49    [19955716]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 3741
iap
Ролг Хупин,

выбираются все данные из таблиц без всяких ограничений?


упрощал и пропустил, есть там ограничение на главную типа такого
...where t1_id in (select t_id from t where parent_id=@parent_id)
1 дек 16, 15:24    [19955915]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
Ролг Хупин,

в простом варианте Recompile + смотреть план, в сложном варианте смотреть план :)
1 дек 16, 15:28    [19955942]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
iap
Member

Откуда: Москва
Сообщений: 47000
Ролг Хупин,

индексы-то хоть какие-нибудь уже есть?
1 дек 16, 15:32    [19955963]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
... where

в этом ...опа кроется.
1 дек 16, 16:26    [19956281]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31430
Ролг Хупин
Есть запрос типа такого, прибольшом количестве записей (> 1млн) работает не быстро и вызывает блокировки.
Смотреть, есть ли индексы на t2_id и т.д.

Если это кластерный ПК, то некоторое ускорение выборки (за счёт замедления вставки) может дать создание некластерных уникальных инедксов вида t2_id include(t2_name)

Ещё нужны индексы на таблицу t1 , соответствующие условиям выборки.

Если в запросе есть строка order by, то индексы должны это учитывать.

Конечно, лучше всего оптимизировать, глядя на план, а не так, умозрительно.

Ну и не забывать, что для получения большого количества данных на клиенте тоже нужно время.
1 дек 16, 18:19    [19956880]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
Idol_111
Member

Откуда:
Сообщений: 605
тут по любому необходим индекс на t1_id, а большего вам никто не сможет подсказать без деталей (план, индексы, размеры таблиц и т.п.).

Хотите избежать блокировок, with(nolock) поможет, если бизнес модель позволяет.
5 дек 16, 02:52    [19966560]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
Sybex
Member

Откуда: Moscow
Сообщений: 109
Idol_111
Хотите избежать блокировок, with(nolock) поможет, если бизнес модель позволяет.

Что за дурацкая привычка советовать использовать хинты налево и направо? Хинты - это самая крайняя мера, когда другие подходы не срабатывают. Ладно, если Вы понимаете для чего нужен этот nolock и к чему это может привести, но куча новичков видят такие советы и думают, что они сейчас всё себе сделают мега быстро и избавятся от блокировок, начнут совать эти хинты во все запросы совершенно бездумно! А потом ещё и другим советовать будут. А что получится в результате?
В данном конкретном случае ТС не приводил плана выполнения запроса, не рассказал какие у него есть индексы. Зачем ему советовать хинты?
5 дек 16, 10:45    [19967129]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
Sybex,

автор
В данном конкретном случае ТС не приводил плана выполнения запроса, не рассказал какие у него есть индексы. Зачем ему советовать хинты?

ради интереса, расскажите нам как повлияет описание индексов на использование NOLOCK
5 дек 16, 10:50    [19967154]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
Sybex
Member

Откуда: Moscow
Сообщений: 109
TaPaK
ради интереса, расскажите нам как повлияет описание индексов на использование NOLOCK

Прямо - никак. Я всего лишь говорил о том, чтобы не учить людей бездумно пихать хинты по поводу и без. А описание индексов нужно для советов по оптимизации конкретного запроса ТС. Возможно после оптимизации у него отпадёт проблема с блокировками. А вот если он всё оптимизирует, но проблема блокировок останется, то вот тут уже и нужны будут советы про NOLOCK, уровень изоляции UNCOMMITED и прочее, прочее, прочее... Проблемы надо решать по мере их поступления.
5 дек 16, 11:31    [19967316]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
Idol_111
Member

Откуда:
Сообщений: 605
Sybex,
вам стоит смотреть на проблему во всем ее объеме, а не выдергивать подходящие факты и параметры.
Изначально имеем БОЛЬШОЙ объем данных и даже если вы поможете парню настроить индексы, с большой долей вероятности запрос все равно будет достаточно медленный и будет блокировать остальный процессы.

Надеюсь вы догадываетесь, что большой объем данных не вытаскивают для того чтобы проанализировать, поправить и запихнуть обратно. Это явно репорт (или типа того). И вот в этом случае абсолютно не профессионально НЕ использовать nolock.

Откуда вы взяли что это последний рубеж? Не надо путать желтое с жирафом, индексы для одного, хинты для другого.
Я своих девелоперов (новых и старых) пинками гоняю, чтобы они использовали хинты где это возможно.

Естественно, вы правы, надо понимать когда и зачем ты их используешь, но айти сфера (и не только) вообще место где в начале надо думать, а потом делать.
5 дек 16, 23:42    [19970371]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
автор
И вот в этом случае абсолютно не профессионально НЕ использовать nolock.

профессионально использовать READUNCOMMITED... ну ну

блокировки решит RCSI(если бизнес модель позволяет), а оптимизировать по куску запроса это фантастика. И да в большинстве своём хинты это больше значит, что вы что-то делаете не так
6 дек 16, 09:56    [19970882]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
Sybex
Member

Откуда: Moscow
Сообщений: 109
TaPaK
Idol_111
И вот в этом случае абсолютно не профессионально НЕ использовать nolock.

профессионально использовать READUNCOMMITED... ну ну

блокировки решит RCSI(если бизнес модель позволяет), а оптимизировать по куску запроса это фантастика. И да в большинстве своём хинты это больше значит, что вы что-то делаете не так

+1
Вот ни прибавить, ни убавить.
6 дек 16, 11:49    [19971472]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 3741
Владислав Колосов
... where

в этом ...опа кроется.


Не совсем, точнее ...опа - она везде, но в данном случае она была в Outer Join-ах.
Убрал их все, точнее заменил на инлайн (select .... from ... where) и стало на порядок быстрее, ну и соответственно ушли dead-овские блокировки.
6 дек 16, 16:23    [19973288]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
NETClient
Member

Откуда:
Сообщений: 461
Ролг Хупин
Убрал их все, точнее заменил на инлайн (select .... from ... where) и стало на порядок быстрее, ну и соответственно ушли dead-овские блокировки.

Cкорее всего уменьшилось не общее время выполнения запроса, а время до первого fetch-а.
6 дек 16, 16:27    [19973300]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
Ролг Хупин,
автор
Убрал их все, точнее заменил на инлайн (select .... from ... where) и стало на порядок быстрее, ну и соответственно ушли dead-овские блокировки.
как это развидеть
6 дек 16, 16:33    [19973325]     Ответить | Цитировать Сообщить модератору
 Re: Можно ли оптимизнуть такой LEFT OUTER JOIN?  [new]
Idol_111
Member

Откуда:
Сообщений: 605
TaPaK
автор
И вот в этом случае абсолютно не профессионально НЕ использовать nolock.

профессионально использовать READUNCOMMITED... ну ну

блокировки решит RCSI(если бизнес модель позволяет), а оптимизировать по куску запроса это фантастика. И да в большинстве своём хинты это больше значит, что вы что-то делаете не так
судя по логики ваших рассуждений вы не админом работаете, а разрабом?
Админ работает с тем что уже создано. И случаи, когда в OLTP систему запихнули (или хотят) что-либо из OLAP (типа репорта или анализа), сплошь и рядом.
И ваше удивление меня удивляет.
Повидимому ваша реальность отличается от моей, и вам повезло больше :).
7 дек 16, 23:31    [19978556]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить