Типовые ошибки в условиях 1С запросов
HTML-код
- Опубликовано: 12 июн 2024
- Хочешь научиться программировать на 1С? Желтый клуб рекомендует курс по 1С от Нетологии: bit.ly/3DZAmTT
А по промокоду yellowclub получишь 10% скидку.
В гостях у Желтого клуба Артём Кузнецов - тимлид в крупнейшей МФО в России.
Артёму есть чем поделиться. Он работает с 1С базой объемом более 7 ТБ.
Это часть большого митапа с Атрёмом. Полную версию митапа по оптимизации 1С запросов смотрите тут: • Оптимизация запросов в...
ДОП. МАТЕРИАЛЫ от Артёма Кузнецова
Презентация и консоль запросов: vk.cc/c8Rxoq
Стандарты оптимизации запросов от фирмы 1С: vk.cc/c9n6sz
НАВИГАЦИЯ
00:00 - Стандарт "Эффективные условия запросов" от фирмы 1С
00:19 - ВЫБРАТЬ в запросах 1С
01:20 - Отрицание в условиях 1С запросов
02:17 - Не используй НЕ ЕСТЬ NULL
04:08 - Почему ИЛИ / В() - это плохо
06:41 - Нельзя использовать ТИПЗНАЧЕНИЯ() в 1С запросах
07:21 - Соединения
08:29 - Пример оптимизации условий в 1С запросе
#желтыйклуб #1с #запросы
==========
Информационные площадки "Жёлтого клуба":
Телеграмм канал: t.me/yellowclub_official
Телеграм чат: t.me/yellowclub_vrn
Группа ВКонтакте: vk: 1c_36
Подписывайся на канала Желтого клуба, чтобы не пропустить интересных гостей
/ @yellow_club
Большое спасибо что собрали самое важное в такое короткое видео)
Да, спасибо Артёму за крутой материал
Полезное видео, спасибо. Интересно было бы посмотреть на все стандарты разработки, которые применяются Автором.
в общем, sql в 1С и так бедный, вы ещё и отменили половину sql😅
Это не типовые ошибки в запросах. Запрос оптимален для решения задачи клиента. Оптимизация это уже второй этап за который нужно отдельно платить. И который может никогда и не наступить.
Можно и так. Такой подход похож на внедрение. Сделаем как умеем, а дальше видно будет.
Когда сидишь на сопровождении, то будешь больше думать об оптимизации
@@yellow_club Вот и готовая тема для ролика. Пригласить фрилансера или разраба из франча которые работают с разными клиентами и задачами в режиме "многозадачности".
Хорошая тема, спасибо. Попробую организовать
Спасибо. Появился вопрос на разделе "Ставить НЕ в условии не надо", но в конце видео ответили на него
Да, меня это тоже смущало)
Я что-то не заметил. Ткните пальцем, где это аргументированно
А вЫ не думали, что чрезмерное использование временных таблиц и их индексация приведет (в большинстве случаев) к гораздо большим просадкам производительности исполнения запросов? ВТ нужно создать, потом еще индекс(ы) построить. Это весьма не маленькие операции. И приоритет должен быть на стороне читаемости, а не максимальной производительности (без фанатизма), пока код пишут люди.
Первый запрос не решает поставленную задачу по критерию времени, потому читаемостью приходится жертвовать. Ну и цифры по времени приведены, было 10 сек, стало 0.5, видимо не так велики накладные расходы на ВТ.
6:41 Не верно, ТипЗначения() = Тип() и Ссылка в скуле получается полностью идентичный код. Вот собственно условие: T1.RecorderTRef = 0x0000019E (в обоих случаях), Запросы полностью идентичны (скулевые). Я не сомневаюсь что Вы хороший программист и умеете писать запросы оптимальные, но Вы хоть проверяйте информацию!!!
Это из той же серии что и Не Есть Null и Есть Не Null. Зачем тратить ресурсы когда можно сразу написать код преобразования. Вместо вызова двух функций быстрее вызвать одну.
В целом я не против использовать небольшие ВТ вместо В, НЕ и пр. НО, как быть с СКД, где юзер ставит произвольные фильтры. Писать движок (функцию), который в скомпонованный макет поменяет текст запроса (не помню, текст(ы) запросов в скомпонованном макете доступны на запись)?
В модуле объекта в событии при формировании результата можно подменить текст запроса
На файловой базе выборка из 30к позиций по условию к перечислению через где и виртуальной таблице составило 3 сек. В пользу виртуальной таблицы. а вот по 2 значениям перечисления через где на 2 секунды быстрее отработало.
Артем по ходу дела не пробовал профайлер запустить и глазками своими собственными посмотреть план. Трахать SQL-сервер менеджментом временных таблиц только чтобы уйти от В() - это настолько кринжово, что... Ну я даже не знаю что сказать... Куда выложить скрины запросов и профайлера? Вот прям взял и накидал два совершенно идентичных представленным запроса по своей довольно большой таблице документов. Второй вариант с внутренними соединениями очевидно же порождает несколько нестед лупсов в отличие от ни одного (максимум одного, если индексы совсем плохие) в первом запросе. Единственная неоптимальность в первом запросе - это использование НАЧАЛОПЕРИОДА/КОНЕЦПЕРИОДА, потому что это не позволяет использовать индексацию документа по дате. На сём и надо было остановиться, а не городить огород. Насчет цифр - первый запрос с исправленным МЕЖДУ у меня CPU:15, Reads:5096, Dura:24. Второй - CPU:47, Reads:40802, Dura:45.
НЕ (шаг = значение()) это отрицание булевого значения?
Типзначения() разве не использует индексированную физическую колонку с типом?
Типзначения = тип и ссылка генерят одинаковый SQL код, но ссылка не работает на несовместимых типов.
Странно. Я читал, что оператор В как раз норм по производительности, потому что вьіполняется как запрос с обьединением. Бьіла рекомендация ИЛИ заменять на В. Может в исходном запросе достаточно бьіло последнее заменить на В из предвіьборки?
Индексирование булево полей мне кажется это гениально сказано (нет).
А чем плохо применение отрицания для булевых значений? Никаких неявных соединений там не будет
Очень много фантазий у ментора. Например передает запросы в планировщик(С точки зрения СУБД, 1С передает не запрос, а инструкцию. Инструкция подает в ОПТИМИЗАТОР. ОПТИМИЗАТОР в свою очереднь делает несколько планов запросов и подбирает оптимальный). По поводу быстродействия запросов , автор упоминул статистику(надо добавить еще КЭШЬ субд), так вот если вы не обновляете статисктику и КЭШЬ (либо не реструктаризируете таблицы БД), то конечно же, стандартизированные запросы будут выполняться быстрее. По поводу индексации ВТ это мрак(ВТ хранятся в оперативной памяти) и если вы их индексируете то из оперативки Вт попадает на хард, есть только один случай индексации ВТ, а именно когда ВТ > 8 мбайт(Потому что если ВТ > 8 мбайт то она всегда помещается из оперативки в хард). Буду сильно удивлен если у ментора есть серт Эксперта.
Если документов много миллиардов и нужно их анализировать, разве не лучше делать регистры, записывать туда предрасчетную информацию(даже хотябы регламентным заданием), индексируй. А потом запросы по уже подготовленным данным...
99% никакой оптимизации не делают. И в 99% она и нафиг не нужна
главная ошибка, это использование 1с как языка. каждый пишет шо хочет и в итоге получилась солянка.
А в других языках разве не так же? Везде каждый пишет шо хочет