0. jan27 683 15.09.14 10:05 Сейчас в теме

Переписываем запросы 1С для повышения производительности на SQL сервере

В идеальном мире не имело бы значение, какой мы используем синтаксис для формирования запроса. Любой логически идентичный запрос должен бы вызывать одинаковый план выполнения с одинаковыми характеристиками производительности.
Для достижения этой цели оптимизатор запросов SQL сервера должен знать различные варианты синтаксиса для конкретной логической конструкции и иметь ресурсы для исследования этих вариантов. В настоящее время такая ситуация просто невозможна.
Можно предположить, что различные синтаксические вариации на тему одного логического запроса могут повлечь за собой разные планы выполнения с отличающимися характеристиками производительности.


Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. Йожкин Кот 1064 15.09.14 17:11 Сейчас в теме
2. AlX0id 15.09.14 23:17 Сейчас в теме
(1) Йожкин Кот,
Случай того, что "неоптимизированный" запрос выигрывает по всем статьям у "оптимизированного"? )
4. jan27 683 16.09.14 10:42 Сейчас в теме
(1) не могу посмотреть, что там?
10. BabySG 18.09.14 09:59 Сейчас в теме
(4) не следует использовать условие по ИЛИ, сделайте через ОБЪЕДИНИТЬ ВСЕ. Кстати, на 1С:Эксперт по это тоже рассказывают.
11. jan27 683 18.09.14 10:57 Сейчас в теме
(10) да, согласен, по ИЛИ отрабатывает медленнее, что и показано в работе
3. Gilev.Vyacheslav 1822 16.09.14 05:18 Сейчас в теме
в этой статье много "теоретических рассуждений" и очередное изобретение велосипеда

все это может не сработать, если в запросе например будет два десятка таблиц, а такой простой запрос в реальной жизни вряд ли будет создавать серьезные проблемы

но такие статьи нужны, пока обучаешь других хотя бы сам учишься )
artbear; flyDrag; Redokov; cleaner_it; zoytsa; awk; exciter; JesteR; mmch; alyaev.a.v; plmshka; shalimski; +12 Ответить
5. jan27 683 16.09.14 10:49 Сейчас в теме
(3) спасибо за внимание. Мне показалось, что рассуждений здесь маловато. Не ставилась задача показать как решать серьезные проблемы. Кстати, а не найдется ли у вас примера запроса, вызывающего Intra-query parallelism deadlocks?
16. zoytsa 19.09.14 14:14 Сейчас в теме
(3) Gilev.Vyacheslav,
интересна вставка временной таблицы, Ваша цитата с gilev.ru


Во многих случая ускорить запрос могут временные таблицы

Сообщение Гилёв Вячеслав » 15 окт 2013, 01:23
... могут, но не всегда.
Сами по себе временные таблицы это просто инструмент, который надо применять понимая плюсы и минусы этой технологии.

Минусы:
для создания временной таблицы требуется время;
для каждого соединения свои изолированные таблицы;
временные таблицы при заполнении большим объемом данных тратят много времени;
создание индексов для временных таблиц это еще дополнительное время;
осторожнее с ораклом, включая 11 версию субд плохо дело со статистикой;
слишком большое количество временных таблиц может занять много места на диске.

Плюсы:
в отличии от вложенных запрос количество строк во временной таблице ПРОГНОЗИРУЕМОЕ, именно "ясность" с объемом выборки делает их удобными для оптимизации мест, которые выполняются неоправдано долго;
временные таблицы не пересекаются по блокировкам;
временные таблицы могут позволить не совершать повторные действия над одними и теме же данным в сложном запросе;
временные таблицы можно использовать для сбора промежуточных результатов из "подзапросов", таким образом это может упростить контроль RLS (т.е. проверке подвергать только итоговые данные, а не все промежуточные действия в сложном запросе).


виртуальные таблицы - это платформенное использование временных таблиц, но иногда бывают ситуации, когда временная таблица из-за большей "управляемости" может быть более интересная, чем виртуальная таблица...
Показать


и еще:

Если в запросе используется соединение с виртуальной таблицей языка запросов "1С:Предприятия" (например, "РегистрНакопления.Товары.Остатки()") и запрос работает с неудовлетворительной производительностью, то рекомендуется вынести обращение к виртуальной таблице в отдельный запрос с сохранением результатов во временной таблице.

Виртуальные таблицы, используемые в языке запросов "1С:Предприятия", могут разворачиваться в подзапросы при трансляции в язык SQL. Это связано с тем, что виртуальная таблица часто (но не всегда) получает данные из нескольких физических таблиц СУБД. Если вы используете соединение с виртуальной таблицей, то на уровне SQL оно может быть в некоторых случаях реализовано как соединение с подзапросом. В этом случае оптимизатор СУБД может точно так же выбрать неоптимальный план, как при работе с подзапросом, использованным в языке "1С:Предприятия" в явном виде
17. Gilev.Vyacheslav 1822 20.09.14 21:45 Сейчас в теме
(16) zoytsa, Не понял сути сообщения, да и лучше писать в наш форум http://www.gilev.ru/forum/, если хотите услышать ответ от нас гарантированно
18. jan27 683 22.09.14 08:51 Сейчас в теме
(17) некрасиво использовать чужую статью для собственной рекламы, уж если начали обсуждать - продолжайте
ya.Avoronov; asylum90; ZLENKO; +3 Ответить
6. PVG_73 17 17.09.14 11:06 Сейчас в теме
Эта статья говорит лишь о том, что оптимизировать можно и почему (поверхностно....)
А на самом деле такие статьи нужно рассматривать на конкретном примере:
Есть объект метаданных у него есть такие реквизиты, по таким то реквизитам строятся индексы.
Далее смотрим как меняется план выполнения SQL при той или иной выборке по данной таблице.
И тогда сразу будет видно отчего именно зависит какой план выполнения выберет SQL.
А в идеале рассмотреть выборку по нескольким таблица и показать как при правильном использовании тех или иных конструкций мы получаем оптимальный план выполнения....
И на самом деле очень хорошо это видно на самом запросе SQL, т.к. транслятор 1С все равно по своему интерпретирует наши запросы к базе.
7. jan27 683 17.09.14 11:54 Сейчас в теме
(6) синтаксис указанных запросов в СКЛ один в один как в 1С разве что англоязычный и поля замененены на имена СКЛ
да. в ходе экспериментов попадались варианты, когда один запрос 1С вызывает множество коротких запросов СКЛ, причем часть из них - работа с временными таблицами,
на мой взгляд такие запросы требуют дополнительного анализа и оптимизации, но это отдельная тема

конкретные примеры сильно привязаны к специфике конкретного запроса, хотелось показать общий подход
8. PVG_73 17 17.09.14 12:37 Сейчас в теме
(7), просто я хотел отметить, что для показа общего подхода так же необходимо было бы упомянуть, что первоначальная структура метаданных имеет тоже не маловажную роль, т.к. включения тех или иных индексов SQL полностью зависит от того как мы описали структуру хранимых данных.
9. jan27 683 17.09.14 14:45 Сейчас в теме
(8) это да, не спорю... но индексы можно и добавить по итогам анализа планов запроса, избыточные индексы тоже не есть гуд
12. AlX0id 19.09.14 10:33 Сейчас в теме
Я бы хотел еще уточнить одну вещь - профайлер показывает помимо длительности запроса еще логические чтения и число строк. Каким образом, например, сравнивать запросы с чуть большей длительностью и меньшим количеством чтений с запросами меньшей длительности, но на порядок большим количеством чтений?
13. jan27 683 19.09.14 12:37 Сейчас в теме
(12) если речь о рабочем сервере, профайлером не рекомендуют пользоваться, а так в профайлере можно группировать по различным колонкам, выгружать данные и сортировать по интересующим колонкам
14. AlX0id 19.09.14 13:17 Сейчас в теме
(13)
Вот меня и интересует, какие колонки должны интересовать в каких случаях %)
15. jan27 683 19.09.14 13:39 Сейчас в теме
(14) в большинстве случаев увеличения колонки Reads влекут за собой и увеличение в колонке Duration
19. lustin 26.09.14 01:24 Сейчас в теме
(0) А все таки у меня вопрос чем вызвана такая любовь к чистой ИТСовской обработке Консоль запросов. Есть же http://infostart.ru/public/56973/
artbear; asylum90; +2 Ответить
20. jan27 683 26.09.14 01:46 Сейчас в теме
(19) если присмотреться, то можно увидеть, что она не чисто ИТС - www.lavelin.ru. Лично мне она нравится тем, что можно применять произвольный код к результату запрса
21. jobkostya1c8 28.01.15 13:08 Сейчас в теме
Полезный материал для специалистов по оптимизации и производительности конфигураций 1С. Вот только Profiler нужно в меру использовать. Иначе как пошутили эти самые оптимизаторы "если запрос все равно в 1С криво выполняется и не понять в чем причина придется в Profiler лезть смотреть. Вот только если ты будешь лазить в профайлер с каждым кривым запросом то будешь два рубля в день получать. Не в смысле две тысячи :)"
22. jan27 683 28.01.15 23:05 Сейчас в теме
(21) а у вас все запросы такие кривые?))
23. crabzzy 28.01.16 12:34 Сейчас в теме
(22) Константин дело говорит.
Мне сегодня пригодилась, например, хранимая процедура sp_WhoIsAcitve, она также позволяет планы запросов получать (причём также в SQL графически его сразу видно). Исполняется так в SQL Server Management Studio:

exec sp_whoisactive
@get_full_inner_text = 0
,@get_plans = 1
,@get_outer_command = 1

Вложил хранимку в zip вложении.
Прикрепленные файлы:
who_is_active_v11_11.zip
24. jan27 683 28.01.16 12:46 Сейчас в теме
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Консультант 1С
Нижний Новгород
зарплата до 100 000 руб.
Полный день


Программист 1С
Бобров
зарплата от 100 000 руб. до 150 000 руб.
Временный (на проект)

Студент (стажер) 1С
Нижний Новгород
зарплата от 25 000 руб.
Полный день

Программист 1С
Санкт-Петербург
зарплата от 120 000 руб.
Полный день