|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
Есть таблица которая содержит документы - генерируемые, либо импортируемые сервером. Documents(ID int identity(1,1) primary key, <набор полей - описание документа>, Body varbinary(max) ). Body - тело документа, в среднем по палате 7800 байт, наибольшая часть документов 300-500 байт. Тормозит запрос к таблице, который который выбирает фильтрованный список документов для просмотра (размер списка ограничен 50 тыс. строк). Для фильтров есть индексы. Body не выбирается, его просмотр и редактирование отдельными средствами. Понятно, что в принципе в ОП поднимается слишком много страниц, потом lookup и т.д. Кроме индексирования, решено поделить таблицу на 2: Код: sql 1. 2. 3.
Изменения не должны сказаться на клиентах, поэтому сверху обновляемый VIEW Код: sql 1. 2. 3. 4.
В итоге запрос на выборку, который выбирает необходимый список, все равно тормозит. Из плана видно, что наибольшую нагрузку дает clustered index seek к Documents_Data. Но никаких полей из нее не выбирается, связь 1-1, PK и внешний ключ указан. Подобный подход (надстройка в виде view) вообще уже используется в БД, лишние таблицы не тянутся в запросы (по крайней мере, там, где это наблюдали). Почему здесь не так? Пока объяснил на пальцах, без планов, может есть простой ответ. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 11:40 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
Matroz Кроме индексирования, решено поделить таблицу на 2 Дешевле выкинуть Body в LOB Код: sql 1.
Но это повысит производительность только если Body в подавляющем большинстве выборок не участвует. P.S. Недавно меня за подобное предложение тут сильно критиковали. Но мой личный опыт показывает востребованность такого подхода. Выбирать Вам. Вставка, обновление и чтение Body при этом замедлится. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 11:51 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
Matroz, уберите d.body и проверьте - будет ли тормозить. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 12:07 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
Владислав Колосов Matroz, уберите d.body и проверьте - будет ли тормозить. Так мне без d.body это представление и не нужно ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 12:34 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
Matroz, это очевидно, вы Вы хотите понять - в каком месте "не работает". ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 13:18 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
Matroz Из плана видно, что наибольшую нагрузку дает clustered index seek к Documents_Data. Но никаких полей из нее не выбирается вот и покажите план. только не картинкой. https://www.brentozar.com/pastetheplan/ ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 13:25 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
Matroz Тормозит запрос к таблице, который который выбирает фильтрованный список документов для просмотра (размер списка ограничен 50 тыс. строк). Для фильтров есть индексы. Body не выбирается, его просмотр и редактирование отдельными средствами. Понятно, что в принципе в ОП поднимается слишком много страниц, потом lookup и т.д. Кроме индексирования, решено поделить таблицу на 2: Пока объяснил на пальцах, без планов, может есть простой ответ. Знатные борцы с тормозами. Чтобы сервер "нетормозил" - заставим его делать лишнюю работу - соединение таблиц. Бред же. Незамутненный. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 13:37 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
да уж, товарищ, если в запросе вьюха, а не 1 таблица в явном виде, соединение все равно надо делать, раз вы его заказали. чтобы не читать таблицу с документами, ПК по id должен быть некластерный, а у вас поди кластерный, потому кластерный и фигурирует в плане ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 13:46 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
aleks222 Чтобы сервер "нетормозил" - заставим его делать лишнюю работу - соединение таблиц. Бред же. Незамутненный. Отличный совет! Но серверу нет нужды соединять таблицы, если используются данные только одной из них. При соблюдении определенных условий (когда разборщик понимает, что это не ограничивающий join) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 13:48 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
Matroz (когда разборщик понимает, что это не ограничивающий join) И как сервер это МОЖЕТ понять, кроме как выполнив соединение? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 13:50 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
ну или если куча не нравится и вью особо хочется, то по ид делайте и кластерный, и некластерный. один как ПК, второй просто уникальный. тогда где не надо боди, подцепит некластерный ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 13:51 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
aleks222И как сервер это МОЖЕТ понять, кроме как выполнив соединение? вот так. Натолкнуло на размышления, может ли. Неверно условие связи записал, теперь может, при наличии уникальности с обеих сторон. Так работает, Documents_Data в плане нет. Код: sql 1. 2. 3. 4.
Yasha123 aleks222 спасибо за активацию мозга. Этот вариант тоже посмотрю (но у нас генерируется скрипт на две БД, в т.ч. Postgres - как он хранит BLOB, пока не рабирался) ptr128EXEC sp_tableoption 'Documents', 'large value types out of row', 1 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 14:43 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
Matroz Так работает, Documents_Data в плане нет. Проверять нужно в результатх statistics io. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 15:29 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
Matroz Так работает, Documents_Data в плане нет. [src] alter view Dоcuments as select m.* /*здесь перечислены все поля вместо m.* */, d.Body from Documents_Main m LEFT OUTER join Documents_Data d on m.ID = d.ID Только ЭТО - необновляемое представление. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 16:45 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
Matroz Postgres - как он хранит BLOB, пока не рабирался Похоже. Механизмом TOAST . Отключить out-of-line для поля можно указанием SET STORAGE PLAIN или MAIN. Форсировать - EXTERNAL или EXTENDED. Граница выталкивания поля в TOAST, в зависимости от его размера, определяется выражением WITH ( toast_tuple_target = n ) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 17:13 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
aleks222 Только ЭТО - необновляемое представление. Я не имел в виду, что оно обновляемое по умолчанию, просто не стал писать На большинстве таблиц триггера висят, для аудита. Здесь будет INSTEAD OF триггер ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2021, 20:30 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
Matroz, зачем Вы добавили в запрос колонку body, если она "не выбирается"? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2021, 02:42 |
|
Запрос данных из представления - "лишние" таблицы в плане запроса
|
|||
---|---|---|---|
#18+
Владислав Колосов, Представление создано для клиентов, которые используют нашу БД. Они работают с документами индивидуально (либо генерируют их небольшими пачками) в прежнем режиме, только теперь будут работать не с таблицей, а с одноименным представлением. Естественно им требуется и описание и содержимое документа (Body). У нас есть приложение, которое реализует в т.ч. групповые операции над документами. Тормозят несколько запросов, которые используются для сравнительно больших выборок, но им как раз и не требуется содержимое документа (на момент просмотра). ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2021, 09:08 |
|
|
start [/forum/topic.php?fid=46&msg=40035949&tid=1685213]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
154ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
others: | 296ms |
total: | 544ms |
0 / 0 |