0. bpc222 2089 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 2089 07.10.16 15:45 Сейчас в теме
4. bpc222 2089 07.10.16 15:46 Сейчас в теме
(1) bulpi,

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

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

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

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


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

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

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

Именно надо подчеркнуть, что в примере расматриваются простые запросы.
YPermitin; Atticus2; Vladimir Litvinenko; mindcannon; Gilev.Vyacheslav; Madsos; sigmov; +7 1 Ответить
13. bpc222 2089 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 2089 10.10.16 08:24 Сейчас в теме
(11) KroVladS,

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

Не гуд....
16. bpc222 2089 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 2089 11.10.16 12:44 Сейчас в теме
(19) kote,

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


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

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

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

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

24. bpc222 2089 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С
Санкт-Петербург
зарплата от 120 000 руб.
Полный день

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

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

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

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