Типовые ошибки в условиях 1С запросов

Поділитися
Вставка
  • Опубліковано 13 січ 2025

КОМЕНТАРІ • 32

  • @arshanskiysergey2791
    @arshanskiysergey2791 3 роки тому +22

    Большое спасибо что собрали самое важное в такое короткое видео)

    • @yellow_club
      @yellow_club  3 роки тому +1

      Да, спасибо Артёму за крутой материал

  • @ІванКіщенко-з7н
    @ІванКіщенко-з7н 3 роки тому +8

    Полезное видео, спасибо. Интересно было бы посмотреть на все стандарты разработки, которые применяются Автором.

  • @ktotoanonimnyj7500
    @ktotoanonimnyj7500 Рік тому

    На файловой базе выборка из 30к позиций по условию к перечислению через где и виртуальной таблице составило 3 сек. В пользу виртуальной таблицы. а вот по 2 значениям перечисления через где на 2 секунды быстрее отработало.

  • @ВасилийДолбак
    @ВасилийДолбак 3 роки тому +2

    Спасибо. Появился вопрос на разделе "Ставить НЕ в условии не надо", но в конце видео ответили на него

    • @yellow_club
      @yellow_club  3 роки тому

      Да, меня это тоже смущало)

    • @Unfound3d
      @Unfound3d 2 роки тому

      Я что-то не заметил. Ткните пальцем, где это аргументированно

  • @timurdanilenko3582
    @timurdanilenko3582 3 роки тому +7

    6:41 Не верно, ТипЗначения() = Тип() и Ссылка в скуле получается полностью идентичный код. Вот собственно условие: T1.RecorderTRef = 0x0000019E (в обоих случаях), Запросы полностью идентичны (скулевые). Я не сомневаюсь что Вы хороший программист и умеете писать запросы оптимальные, но Вы хоть проверяйте информацию!!!

    • @andreykot7577
      @andreykot7577 2 роки тому +1

      Это из той же серии что и Не Есть Null и Есть Не Null. Зачем тратить ресурсы когда можно сразу написать код преобразования. Вместо вызова двух функций быстрее вызвать одну.

  • @Mrnuctoh
    @Mrnuctoh Рік тому +3

    Артем по ходу дела не пробовал профайлер запустить и глазками своими собственными посмотреть план. Трахать SQL-сервер менеджментом временных таблиц только чтобы уйти от В() - это настолько кринжово, что... Ну я даже не знаю что сказать... Куда выложить скрины запросов и профайлера? Вот прям взял и накидал два совершенно идентичных представленным запроса по своей довольно большой таблице документов. Второй вариант с внутренними соединениями очевидно же порождает несколько нестед лупсов в отличие от ни одного (максимум одного, если индексы совсем плохие) в первом запросе. Единственная неоптимальность в первом запросе - это использование НАЧАЛОПЕРИОДА/КОНЕЦПЕРИОДА, потому что это не позволяет использовать индексацию документа по дате. На сём и надо было остановиться, а не городить огород. Насчет цифр - первый запрос с исправленным МЕЖДУ у меня CPU:15, Reads:5096, Dura:24. Второй - CPU:47, Reads:40802, Dura:45.

  • @timurdanilenko3582
    @timurdanilenko3582 3 роки тому +4

    В целом я не против использовать небольшие ВТ вместо В, НЕ и пр. НО, как быть с СКД, где юзер ставит произвольные фильтры. Писать движок (функцию), который в скомпонованный макет поменяет текст запроса (не помню, текст(ы) запросов в скомпонованном макете доступны на запись)?

    • @maxim_gun1
      @maxim_gun1 3 роки тому

      В модуле объекта в событии при формировании результата можно подменить текст запроса

  • @юзверь-9й
    @юзверь-9й Рік тому +11

    в общем, sql в 1С и так бедный, вы ещё и отменили половину sql😅

  • @olegshpilevoy
    @olegshpilevoy 3 роки тому +14

    Это не типовые ошибки в запросах. Запрос оптимален для решения задачи клиента. Оптимизация это уже второй этап за который нужно отдельно платить. И который может никогда и не наступить.

    • @yellow_club
      @yellow_club  3 роки тому +5

      Можно и так. Такой подход похож на внедрение. Сделаем как умеем, а дальше видно будет.
      Когда сидишь на сопровождении, то будешь больше думать об оптимизации

    • @olegshpilevoy
      @olegshpilevoy 3 роки тому

      @@yellow_club Вот и готовая тема для ролика. Пригласить фрилансера или разраба из франча которые работают с разными клиентами и задачами в режиме "многозадачности".

    • @yellow_club
      @yellow_club  3 роки тому

      Хорошая тема, спасибо. Попробую организовать

  • @timurdanilenko3582
    @timurdanilenko3582 3 роки тому +9

    А вЫ не думали, что чрезмерное использование временных таблиц и их индексация приведет (в большинстве случаев) к гораздо большим просадкам производительности исполнения запросов? ВТ нужно создать, потом еще индекс(ы) построить. Это весьма не маленькие операции. И приоритет должен быть на стороне читаемости, а не максимальной производительности (без фанатизма), пока код пишут люди.

    • @PupaVaskin
      @PupaVaskin 3 роки тому +3

      Первый запрос не решает поставленную задачу по критерию времени, потому читаемостью приходится жертвовать. Ну и цифры по времени приведены, было 10 сек, стало 0.5, видимо не так велики накладные расходы на ВТ.

  • @semalex_7580
    @semalex_7580 5 місяців тому

    Что если условия поместить в соединение?

  • @ilya2184
    @ilya2184 3 роки тому +1

    НЕ (шаг = значение()) это отрицание булевого значения?

  • @Александр-п8ы8г
    @Александр-п8ы8г Рік тому +4

    Очень много фантазий у ментора. Например передает запросы в планировщик(С точки зрения СУБД, 1С передает не запрос, а инструкцию. Инструкция подает в ОПТИМИЗАТОР. ОПТИМИЗАТОР в свою очереднь делает несколько планов запросов и подбирает оптимальный). По поводу быстродействия запросов , автор упоминул статистику(надо добавить еще КЭШЬ субд), так вот если вы не обновляете статисктику и КЭШЬ (либо не реструктаризируете таблицы БД), то конечно же, стандартизированные запросы будут выполняться быстрее. По поводу индексации ВТ это мрак(ВТ хранятся в оперативной памяти) и если вы их индексируете то из оперативки Вт попадает на хард, есть только один случай индексации ВТ, а именно когда ВТ > 8 мбайт(Потому что если ВТ > 8 мбайт то она всегда помещается из оперативки в хард). Буду сильно удивлен если у ментора есть серт Эксперта.

  • @ilya2184
    @ilya2184 3 роки тому

    Типзначения() разве не использует индексированную физическую колонку с типом?

    • @Skarbovoy
      @Skarbovoy 3 роки тому

      Типзначения = тип и ссылка генерят одинаковый SQL код, но ссылка не работает на несовместимых типов.

  • @DimaVort
    @DimaVort Рік тому +1

    Странно. Я читал, что оператор В как раз норм по производительности, потому что вьіполняется как запрос с обьединением. Бьіла рекомендация ИЛИ заменять на В. Может в исходном запросе достаточно бьіло последнее заменить на В из предвіьборки?

  • @ГригорийАхметгалеев

    Индексирование булево полей мне кажется это гениально сказано (нет).

  • @ytoteay
    @ytoteay 2 місяці тому

    Много спорных моментов которые только запутывают

  • @jinkisaragi9931
    @jinkisaragi9931 2 роки тому

    А чем плохо применение отрицания для булевых значений? Никаких неявных соединений там не будет

  • @netan7633
    @netan7633 Рік тому

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

  • @Владимир-ь7о9и
    @Владимир-ь7о9и Рік тому +3

    99% никакой оптимизации не делают. И в 99% она и нафиг не нужна

  • @bomgfuf2515
    @bomgfuf2515 3 роки тому

    главная ошибка, это использование 1с как языка. каждый пишет шо хочет и в итоге получилась солянка.

    • @yellow_club
      @yellow_club  3 роки тому +6

      А в других языках разве не так же? Везде каждый пишет шо хочет