0. bpc222 2094 14.09.16 12:17 Сейчас в теме

Оптимизация запросов 1С:Предприятие – от теории к практике

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

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

Комментарии
Избранное Подписка Сортировка: Древо
1. bulpi 155 07.10.16 11:47 Сейчас в теме
Плюс поставил, но :
1)Мало полезной информации, много рекламы
2)Пример на рис.8 вообще не о чем. В комментарии написано "обращение к полям составного типа без типизации" , но пример к типизации не относится.

2. headMade 140 07.10.16 14:00 Сейчас в теме
(1) bulpi,
"обращение к полям составного типа без типизации" там прописано Регистратор.Контрагент
Регистратор - поле составного типа.
Предполагается что прежде чем получать значение "Контрагент" само значение "Регистратор" необходимо было типизировать.
3. bpc222 2094 07.10.16 15:45 Сейчас в теме
4. bpc222 2094 07.10.16 15:46 Сейчас в теме
(1) bulpi,

спасибо. цель прошлогоднего выступления была в том, чтобы продемонстрировать интерактивные инструменты обучения, которые даже запросы могут сравнивать.
5. maddy 17 07.10.16 21:49 Сейчас в теме
В статье описаны интересные практические моменты и недостатки "оптимизации по книжке"
Первая картинка исключительно хороша!
9. logarifm 1045 09.10.16 10:16 Сейчас в теме
Ну на первом примере очевидно, что ВТ проиграет. Потому как идет вставка и заполнение ВТ. ВТ - это не панацея и ее ненужно пихать где только вздумается. Это ест-но, что документ мгновенно будет найден по ссылке из базы, чем произойде вначале го поиск, наполнение ВТ.

В даном простом случае ВТ - избыточное решение. Но вот если у Вас к примеру 10 виртуальных таблиц, вот здесь уже надо сравнивать по-другому.

Автор нельзя так рвать из контекста .... ВТ надо применять, когда это действительно необходимо!!!

Итак, в первом примере вы видите, что идет обращение к виртуальной таблице остатков. При этом в первом случае для отбора по товарам документа используется вложенный запрос, а во втором случае – вложенный запрос с использованием временной таблицы, что, по идее, должно предоставить нам возможности для более эффективной работы с данными. Однако этого не происходит.


Извените, но это полнейшая белеберда. Это равносльно тому, что вначале получить Справочник Номенклатура и заполнить его в ВТ и сделать выборку по ВТ , и сказать - ну я ожидал прирост ведь я использую ВТ.... Бред. Автору рекомендую выкладывать более сложные варианты, то что предложенно абсолютно не правильный пример сравнения!!!

Тьфу-ты, да статья вся написана на одном не правильном примере сравнения. Не стоит усилий и уж тем более людей собьет с правильного пути. Статья должна называтся асболютно не так.

Ндао назвать - где не стоит применять временной таблицы или что-то тип такого... Или ВТ это не панацея оптимизации в простых запросах!!!!

Именно надо подчеркнуть, что в примере расматриваются простые запросы.
YPermitin; Atticus2; Vladimir Litvinenko; mindcannon; Gilev.Vyacheslav; Madsos; sigmov; +7 1 Ответить
13. bpc222 2094 10.10.16 08:23 Сейчас в теме
(9) logarifm,

Александр, все просто... у всего, что я делаю есть цель, смысл, намерения. Посмотрите предыдущие посты :). В них предлагаю партнерам вести работу на своем поле и при наличии предложений направлять их с позиции взаимного уважения и доверия.

И так, отвечаю вам кратко. Эта статья имеет свое позиционирование, свою целевую аудиторию и т.д. Моя задача была примерно следующей - сделать материал для большинства людей, для которых вопросы оптимизации являются новыми, не раскрытыми. Именно им может быть интересно обучение. Если Вам что-то "очевидно", то для большинства, как показывает практика, это так: "да? а почему? а как надо?".

Так что не вырываю я из контекста. За рекомендацию спасибо, только куда с ней :)))
11. KroVladS 31 09.10.16 20:34 Сейчас в теме
(0) Вы осознано вкладывали тайный смысл в первую картинку?
Или "так получилось"?
madonov; rabota.v8.1c; vasiliy_b; Drizer2000; sergelemon; dj_serega; Westbound; tehas; ardarik; ABudnikov; json; +11 Ответить
14. bpc222 2094 10.10.16 08:24 Сейчас в теме
(11) KroVladS,

:) я не специально
15. sigmov 10.10.16 08:52 Сейчас в теме
1. Сначала было сказано про причины возникновения (ну 4ка)
2. Потом были разобраны несколько примеров (на 3ку) с выводом что все очень гибко и использовать нужно когда-так, а когда-не так
3. Ну и наконец "Покупайте наши помидоры"

Не гуд....
16. bpc222 2094 10.10.16 09:51 Сейчас в теме
(15) sigmov,

так не покупайте :)
Статья знакомит с технологией и, заметьте, не предлагает никому ничего покупать.
17. HardBall 10.10.16 10:17 Сейчас в теме
"П"
"А"
"Д"
"Л"
"А"
Только я заметил на первом рисунке?
user660224_laa; artfa; +2 Ответить
18. pirm2 10.10.16 12:39 Сейчас в теме
19. kote 499 10.10.16 13:49 Сейчас в теме
2 более-менее ценных подхода - тут, но способы предложены не корректные, ИМХО:
- Ограничение источников. Но сделано это тут неправильно. "Выразить" - это неправильный подход. Нужно использовать для этого условие с "Ссылка"..
- Индексы. Но на практике - это связано с использованием ВременныхТаблиц. А Вы их заругали за зря. Совет простой - поля ВременныхТаблиц, по которым будете их а) объединять с другими таблицами б) использовать для фильтров (в части условий запроса - после ГДЕ) полезно проиндексировать..

История с избеганием ИЛИ, создавая объединения - вопрос неоднозначный.. Сложную логику таким образом очень сложно реализовать. Читабельность запроса и проверка его соответсвия ТЗ - практически станет нереально проверить.. Выигрыш же будет не особо большим, чтоб пожертвовать указанными вещами.. В общем, это скорее антипаттерн, чем хороший совет.

На практике же наибольший выигрыш можно получить, например, отказавшись от использования выражения:
"Подразделение.Ссылка В ИЕРАРХИИ (&Подразделение)".. не зря аналога в SQL не существует.. ой, не зря.

Последний раз я получил ускорение порядка в ~30 раз (3000%) убрав это безобразие из запроса, предварительно отобрав то, что должно быть в иерархии во временную таблицу с индексированием (на всякий случай) и потом используя её таким макаром:

"Подразделение.Ссылка В (Выбрать ВТ_Подразделения.Ссылка ИЗ ВТ_Подразделения КАК ВТ_Подразделения)"..

Таким образом, ваш совет - не использовать вложенные запросы в условиях запроса и в соединениях - тоже скорее вреден, чем полезен. Хотя - всё хорошо в меру, естественно..

Слайды красивые.
25. bpc222 2094 11.10.16 12:44 Сейчас в теме
(19) kote,

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


Я удивлен указанием вами в обратной связи того, что в статье советуется тот или иной метод... :)
Заметьте, здесь рассмотрены примеры с указанием того, какие достигнуты результаты, используя тот или иной подход выборки/изменения структуры...
Здесь нет симпатий к одному методу или другому, я не советую использовать или не использовать одно или другое...

В любом случае, ваши указания будут, полагаю, ценными для сообщества.
20. HAMMER_59 169 10.10.16 13:54 Сейчас в теме
"Безусловно, самым часто встречающимся случаем является неиспользование отборов внутри виртуальных таблиц. Я думаю, что нет ни одного разработчика 1С, кто не знает этого правила, однако в реальных решениях такие ошибки все-таки встречаются довольно часто. Причем их могут совершать даже разработчики с многолетним стажем."

Я вижу обратное - многие пытаются максимальное количество условий прописать в виртуальных таблицах.
Подозреваю, мало кто задается вопросом: "А как же потом SQL будет отбирать данные?".
Так вот, если указать много отборов - по-разному будет отбирать. И это очень прекрасно. По одному и тому же запросу, в зависимости от входных данных, будет построен различный план запроса. В итоге на выходе имеем запрос, который в зависимости от ситуации, будет выполнятся очень по разному.

ИМХО нужно стремится, чтобы максимально эффективно использовались индексы. А как SQL заставить использовать конкретные индексы, вот об этом в статье ни слова.
Да и про сами индексы в статье ни слова, все ведь и так про них всё знают.

24. bpc222 2094 11.10.16 12:31 Сейчас в теме
(20) HAMMER_59,

"попасть в индекс" - важная задача, конечно же...

Сделал поиск по статье, слово "индекс" встречается около 20 раз...
Про конкретный индекс представлено решение с использованием критерия отбора...
21. Sheff 10.10.16 17:16 Сейчас в теме
26. kkkelena1963 17.10.16 06:23 Сейчас в теме
А я хочу сказать спасибо автору даже за то, что есть над чем подумать и обсудить.
27. alest 10.01.18 12:59 Сейчас в теме
Что-то я не понял про замену запроса к критерию отбора. Ваша замена неравнозначна. Добавьте РАЗЛИЧНЫЕ и уберите ВСЕ из объединения - тогда и сравните.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

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

Руководитель проекта, аналитик, консультант
Санкт-Петербург
По совместительству

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

Бизнес-аналитик 1С
Москва
зарплата от 140 000 руб. до 200 000 руб.
Полный день