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

Откуда: Киров, Россия
Сообщений: 1122
В системе есть вьюшка джойном объединяющая кучу таблиц и фактически представляющая собой всю БД собранную воедино.
Народ привык делать на нее прямые запросы для отчетов, типа select * from vw_report where ....

Сама вьюха представляет собой базовую таблицу base на которую зацеплено огромное количество справочников. В чем собственно говоря проблема. Проблема в том что когда человек пишет запрос select * from vw_report where id=xxx где id фактически является основным полем базовой таблицы base в вьюхе vw_report то парсер сначала объединяет все таблицы в vw_report что долго и только потом берет строку с указанным id. При этом id это кластерный PK на базовой таблице base.
Отсюда вопрос, что можно сделать дабы парсер сначала производил бы поиск по id в таблице base, а уже потом делал портянки джойнов для vw_report, а не наоборот.
25 окт 18, 12:45    [21714717]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
TaPaK
Member

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

автор
парсер сначала объединяет все таблицы в vw_report что долго и только потом берет строку с указанным id

Откуда такой вывод? И что кто этот "парсер"?
25 окт 18, 12:47    [21714722]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
энди
Member

Откуда: Киров, Россия
Сообщений: 1122
делаю запроc select * from vw_report where id=xxx по плану вижу что идут сначала джойны таблиц, а уже потом выбор одной строки,
итого 7 секунд
а если делаю
select * from base
join....
... (тут полная копия всех джойнов из vw_report)
join ...
where base.id=xxx
то выполняется моментом и план показывает что сначала выбирается запись из base и все остальное уже цепляется на эту одну запись
25 окт 18, 12:58    [21714734]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
iiyama
Member

Откуда:
Сообщений: 642
энди,

Есть ли у вас план, мистер Фикс?
Есть ли у меня план? Есть ли у меня план? Да у меня целых три плана!
(с) Мистер Фикс
25 окт 18, 12:59    [21714735]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
энди
делаю запроc select * from vw_report where id=xxx по плану вижу что идут сначала джойны таблиц, а уже потом выбор одной строки,
итого 7 секунд
а если делаю
select * from base
join....
... (тут полная копия всех джойнов из vw_report)
join ...
where base.id=xxx
то выполняется моментом и план показывает что сначала выбирается запись из base и все остальное уже цепляется на эту одну запись

планы показывайте. Или FORCE ORDER
25 окт 18, 13:03    [21714738]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
энди
В системе есть вьюшка джойном объединяющая кучу таблиц и фактически представляющая собой всю БД собранную воедино.
Народ привык делать на нее прямые запросы для отчетов, типа select * from vw_report where ....

Сама вьюха представляет собой базовую таблицу base на которую зацеплено огромное количество справочников. В чем собственно говоря проблема. Проблема в том что когда человек пишет запрос select * from vw_report where id=xxx где id фактически является основным полем базовой таблицы base в вьюхе vw_report то парсер сначала объединяет все таблицы в vw_report что долго и только потом берет строку с указанным id. При этом id это кластерный PK на базовой таблице base.
Отсюда вопрос, что можно сделать дабы парсер сначала производил бы поиск по id в таблице base, а уже потом делал портянки джойнов для vw_report, а не наоборот.

Если написано внутри view джойны в виде left hash join или inner hash join - то сервер будет сначала читать таблицу base и все таблицы справочников, а потом уже отбирать одну строку по id. Если внутри view такие же простые join, как и в запросе, написанном "вручную", то возникает подозрение, что условие where base.id=xxx для "ручного запроса" совсем не так выглядит внутри view, там может быть on base.id = sprav1.base_id where base.dop_column = yyy или что-нибудь типа where base.id = convert(varchar(3),xxx).

Поэтому без полного текста view какой смысл гадать на кофейной гуще?
25 окт 18, 14:32    [21714900]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
invm
Member

Откуда: Москва
Сообщений: 9348
Andy_OLAP
Если написано внутри view джойны в виде left hash join или inner hash join - то сервер будет сначала читать таблицу base и все таблицы справочников, а потом уже отбирать одну строку по id.
Как интересно. И у вас наверняка найдется и пример, и объяснения такого поведения?
25 окт 18, 14:51    [21714929]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36972
Andy_OLAP
Если написано внутри view джойны в виде left hash join или inner hash join - то сервер будет сначала читать таблицу base и все таблицы справочников, а потом уже отбирать одну строку по id. Если внутри view такие же простые join, как и в запросе, написанном "вручную", то возникает подозрение, что условие where base.id=xxx для "ручного запроса" совсем не так выглядит внутри view, там может быть on base.id = sprav1.base_id where base.dop_column = yyy или что-нибудь типа where base.id = convert(varchar(3),xxx).

Поэтому без полного текста view какой смысл гадать на кофейной гуще?
Это вы пытаетсь сказать, что при наличии локальных хинтов predicate pushdown никогда работать не будет?
25 окт 18, 14:57    [21714941]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Гавриленко Сергей Алексеевич
Andy_OLAP
Если написано внутри view джойны в виде left hash join или inner hash join - то сервер будет сначала читать таблицу base и все таблицы справочников, а потом уже отбирать одну строку по id. Если внутри view такие же простые join, как и в запросе, написанном "вручную", то возникает подозрение, что условие where base.id=xxx для "ручного запроса" совсем не так выглядит внутри view, там может быть on base.id = sprav1.base_id where base.dop_column = yyy или что-нибудь типа where base.id = convert(varchar(3),xxx).

Поэтому без полного текста view какой смысл гадать на кофейной гуще?
Это вы пытаетсь сказать, что при наличии локальных хинтов predicate pushdown никогда работать не будет?

Я пытаюсь автору темы донести, что если он написал select и join руками, а потом увидел похожие слова внутри view - это совсе не означает, что where xx.yy = zz означает одно и тоже.
И поэтому жду от него здесь полный текст view.
25 окт 18, 15:00    [21714949]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
invm
Member

Откуда: Москва
Сообщений: 9348
Andy_OLAP
Я пытаюсь автору темы донести, что если он написал select и join руками, а потом увидел похожие слова внутри view - это совсе не означает, что where xx.yy = zz означает одно и тоже.
Да нет. Вы написали очередную чушь, а теперь пытаетесь вывернуться.
25 окт 18, 15:11    [21714953]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
энди
Member

Откуда: Киров, Россия
Сообщений: 1122
Постараюсь собрать пример, просто основная структура да и данные скажем так не совсем для публичного доступа.
25 окт 18, 15:46    [21714989]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
invm
Member

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

План лучше покажите. Актуальный.
SentryOne Plan Explorer умеет анонимизировать планы.
25 окт 18, 16:16    [21715052]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31355
энди
Постараюсь собрать пример, просто основная структура да и данные скажем так не совсем для публичного доступа.
Если не можете показывать имена, то покажите вьюху, заменив названия таблиц

Ещё лучше показать план, но он большой, там сложнее менять имена.

PS А вообще невозможность "показывать" означает невозможность пользоваться интернетом при разработке. Тогда нужно формировать команду с очень-очень большим запасом.
Впрочем, на это вы повлиять не можете :-(
25 окт 18, 19:12    [21715281]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
PizzaPizza
Member

Откуда:
Сообщений: 369
энди
делаю запроc select * from vw_report where id=xxx по плану вижу что идут сначала джойны таблиц, а уже потом выбор одной строки


Правильно ли я понял, что если вы мышей на стрелки к джойну в актуальном плане наводите, то вам говорят, что актуальное количество строк = кардинальности всей таблицы для каждой таблицы джойна?
25 окт 18, 19:35    [21715308]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
PizzaPizza
Member

Откуда:
Сообщений: 369
PizzaPizza,

Сорри, для таблицы base вашего view запроса интересует количество строк к джойну, конечно же.
25 окт 18, 19:39    [21715314]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
Владимир Затуливетер
Member

Откуда:
Сообщений: 427
invm
План лучше покажите. Актуальный.
SentryOne Plan Explorer умеет анонимизировать планы.

+1

https://www.sentryone.com/plan-explorer
25 окт 18, 20:00    [21715339]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
энди
Member

Откуда: Киров, Россия
Сообщений: 1122
ребят спасибо за советы, отдельное спасибо за Plan Explorer
Я сейчас сначала попробую порыть сам с использованием Ваших советов и PE, ну а если уж неполучится то приду снова.
26 окт 18, 08:49    [21715605]     Ответить | Цитировать Сообщить модератору
 Re: Работа с большой вьюшкой  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
энди
делаю запроc select * from vw_report where id=xxx по плану вижу что идут сначала джойны таблиц, а уже потом выбор одной строки,
итого 7 секунд
а если делаю
select * from base
join....
... (тут полная копия всех джойнов из vw_report)
join ...
where base.id=xxx
то выполняется моментом и план показывает что сначала выбирается запись из base и все остальное уже цепляется на эту одну запись
Сделайте не так как вы написали, а возьмите целиком весь SELECT из вью, включая WHERE и все остальное. в этом случае план и скорость должны быть идентичными, а потом убирайте постепенно джойны/условия и поймете в чем затык.
27 окт 18, 02:55    [21716692]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить