На файловой базе выборка из 30к позиций по условию к перечислению через где и виртуальной таблице составило 3 сек. В пользу виртуальной таблицы. а вот по 2 значениям перечисления через где на 2 секунды быстрее отработало.
6:41 Не верно, ТипЗначения() = Тип() и Ссылка в скуле получается полностью идентичный код. Вот собственно условие: T1.RecorderTRef = 0x0000019E (в обоих случаях), Запросы полностью идентичны (скулевые). Я не сомневаюсь что Вы хороший программист и умеете писать запросы оптимальные, но Вы хоть проверяйте информацию!!!
Это из той же серии что и Не Есть Null и Есть Не Null. Зачем тратить ресурсы когда можно сразу написать код преобразования. Вместо вызова двух функций быстрее вызвать одну.
Артем по ходу дела не пробовал профайлер запустить и глазками своими собственными посмотреть план. Трахать SQL-сервер менеджментом временных таблиц только чтобы уйти от В() - это настолько кринжово, что... Ну я даже не знаю что сказать... Куда выложить скрины запросов и профайлера? Вот прям взял и накидал два совершенно идентичных представленным запроса по своей довольно большой таблице документов. Второй вариант с внутренними соединениями очевидно же порождает несколько нестед лупсов в отличие от ни одного (максимум одного, если индексы совсем плохие) в первом запросе. Единственная неоптимальность в первом запросе - это использование НАЧАЛОПЕРИОДА/КОНЕЦПЕРИОДА, потому что это не позволяет использовать индексацию документа по дате. На сём и надо было остановиться, а не городить огород. Насчет цифр - первый запрос с исправленным МЕЖДУ у меня CPU:15, Reads:5096, Dura:24. Второй - CPU:47, Reads:40802, Dura:45.
В целом я не против использовать небольшие ВТ вместо В, НЕ и пр. НО, как быть с СКД, где юзер ставит произвольные фильтры. Писать движок (функцию), который в скомпонованный макет поменяет текст запроса (не помню, текст(ы) запросов в скомпонованном макете доступны на запись)?
Это не типовые ошибки в запросах. Запрос оптимален для решения задачи клиента. Оптимизация это уже второй этап за который нужно отдельно платить. И который может никогда и не наступить.
Можно и так. Такой подход похож на внедрение. Сделаем как умеем, а дальше видно будет. Когда сидишь на сопровождении, то будешь больше думать об оптимизации
@@yellow_club Вот и готовая тема для ролика. Пригласить фрилансера или разраба из франча которые работают с разными клиентами и задачами в режиме "многозадачности".
А вЫ не думали, что чрезмерное использование временных таблиц и их индексация приведет (в большинстве случаев) к гораздо большим просадкам производительности исполнения запросов? ВТ нужно создать, потом еще индекс(ы) построить. Это весьма не маленькие операции. И приоритет должен быть на стороне читаемости, а не максимальной производительности (без фанатизма), пока код пишут люди.
Первый запрос не решает поставленную задачу по критерию времени, потому читаемостью приходится жертвовать. Ну и цифры по времени приведены, было 10 сек, стало 0.5, видимо не так велики накладные расходы на ВТ.
Очень много фантазий у ментора. Например передает запросы в планировщик(С точки зрения СУБД, 1С передает не запрос, а инструкцию. Инструкция подает в ОПТИМИЗАТОР. ОПТИМИЗАТОР в свою очереднь делает несколько планов запросов и подбирает оптимальный). По поводу быстродействия запросов , автор упоминул статистику(надо добавить еще КЭШЬ субд), так вот если вы не обновляете статисктику и КЭШЬ (либо не реструктаризируете таблицы БД), то конечно же, стандартизированные запросы будут выполняться быстрее. По поводу индексации ВТ это мрак(ВТ хранятся в оперативной памяти) и если вы их индексируете то из оперативки Вт попадает на хард, есть только один случай индексации ВТ, а именно когда ВТ > 8 мбайт(Потому что если ВТ > 8 мбайт то она всегда помещается из оперативки в хард). Буду сильно удивлен если у ментора есть серт Эксперта.
Странно. Я читал, что оператор В как раз норм по производительности, потому что вьіполняется как запрос с обьединением. Бьіла рекомендация ИЛИ заменять на В. Может в исходном запросе достаточно бьіло последнее заменить на В из предвіьборки?
Если документов много миллиардов и нужно их анализировать, разве не лучше делать регистры, записывать туда предрасчетную информацию(даже хотябы регламентным заданием), индексируй. А потом запросы по уже подготовленным данным...
Большое спасибо что собрали самое важное в такое короткое видео)
Да, спасибо Артёму за крутой материал
Полезное видео, спасибо. Интересно было бы посмотреть на все стандарты разработки, которые применяются Автором.
На файловой базе выборка из 30к позиций по условию к перечислению через где и виртуальной таблице составило 3 сек. В пользу виртуальной таблицы. а вот по 2 значениям перечисления через где на 2 секунды быстрее отработало.
Спасибо. Появился вопрос на разделе "Ставить НЕ в условии не надо", но в конце видео ответили на него
Да, меня это тоже смущало)
Я что-то не заметил. Ткните пальцем, где это аргументированно
6:41 Не верно, ТипЗначения() = Тип() и Ссылка в скуле получается полностью идентичный код. Вот собственно условие: T1.RecorderTRef = 0x0000019E (в обоих случаях), Запросы полностью идентичны (скулевые). Я не сомневаюсь что Вы хороший программист и умеете писать запросы оптимальные, но Вы хоть проверяйте информацию!!!
Это из той же серии что и Не Есть Null и Есть Не Null. Зачем тратить ресурсы когда можно сразу написать код преобразования. Вместо вызова двух функций быстрее вызвать одну.
Артем по ходу дела не пробовал профайлер запустить и глазками своими собственными посмотреть план. Трахать SQL-сервер менеджментом временных таблиц только чтобы уйти от В() - это настолько кринжово, что... Ну я даже не знаю что сказать... Куда выложить скрины запросов и профайлера? Вот прям взял и накидал два совершенно идентичных представленным запроса по своей довольно большой таблице документов. Второй вариант с внутренними соединениями очевидно же порождает несколько нестед лупсов в отличие от ни одного (максимум одного, если индексы совсем плохие) в первом запросе. Единственная неоптимальность в первом запросе - это использование НАЧАЛОПЕРИОДА/КОНЕЦПЕРИОДА, потому что это не позволяет использовать индексацию документа по дате. На сём и надо было остановиться, а не городить огород. Насчет цифр - первый запрос с исправленным МЕЖДУ у меня CPU:15, Reads:5096, Dura:24. Второй - CPU:47, Reads:40802, Dura:45.
В целом я не против использовать небольшие ВТ вместо В, НЕ и пр. НО, как быть с СКД, где юзер ставит произвольные фильтры. Писать движок (функцию), который в скомпонованный макет поменяет текст запроса (не помню, текст(ы) запросов в скомпонованном макете доступны на запись)?
В модуле объекта в событии при формировании результата можно подменить текст запроса
в общем, sql в 1С и так бедный, вы ещё и отменили половину sql😅
Это не типовые ошибки в запросах. Запрос оптимален для решения задачи клиента. Оптимизация это уже второй этап за который нужно отдельно платить. И который может никогда и не наступить.
Можно и так. Такой подход похож на внедрение. Сделаем как умеем, а дальше видно будет.
Когда сидишь на сопровождении, то будешь больше думать об оптимизации
@@yellow_club Вот и готовая тема для ролика. Пригласить фрилансера или разраба из франча которые работают с разными клиентами и задачами в режиме "многозадачности".
Хорошая тема, спасибо. Попробую организовать
А вЫ не думали, что чрезмерное использование временных таблиц и их индексация приведет (в большинстве случаев) к гораздо большим просадкам производительности исполнения запросов? ВТ нужно создать, потом еще индекс(ы) построить. Это весьма не маленькие операции. И приоритет должен быть на стороне читаемости, а не максимальной производительности (без фанатизма), пока код пишут люди.
Первый запрос не решает поставленную задачу по критерию времени, потому читаемостью приходится жертвовать. Ну и цифры по времени приведены, было 10 сек, стало 0.5, видимо не так велики накладные расходы на ВТ.
Что если условия поместить в соединение?
НЕ (шаг = значение()) это отрицание булевого значения?
Очень много фантазий у ментора. Например передает запросы в планировщик(С точки зрения СУБД, 1С передает не запрос, а инструкцию. Инструкция подает в ОПТИМИЗАТОР. ОПТИМИЗАТОР в свою очереднь делает несколько планов запросов и подбирает оптимальный). По поводу быстродействия запросов , автор упоминул статистику(надо добавить еще КЭШЬ субд), так вот если вы не обновляете статисктику и КЭШЬ (либо не реструктаризируете таблицы БД), то конечно же, стандартизированные запросы будут выполняться быстрее. По поводу индексации ВТ это мрак(ВТ хранятся в оперативной памяти) и если вы их индексируете то из оперативки Вт попадает на хард, есть только один случай индексации ВТ, а именно когда ВТ > 8 мбайт(Потому что если ВТ > 8 мбайт то она всегда помещается из оперативки в хард). Буду сильно удивлен если у ментора есть серт Эксперта.
Типзначения() разве не использует индексированную физическую колонку с типом?
Типзначения = тип и ссылка генерят одинаковый SQL код, но ссылка не работает на несовместимых типов.
Странно. Я читал, что оператор В как раз норм по производительности, потому что вьіполняется как запрос с обьединением. Бьіла рекомендация ИЛИ заменять на В. Может в исходном запросе достаточно бьіло последнее заменить на В из предвіьборки?
Индексирование булево полей мне кажется это гениально сказано (нет).
Много спорных моментов которые только запутывают
А чем плохо применение отрицания для булевых значений? Никаких неявных соединений там не будет
Если документов много миллиардов и нужно их анализировать, разве не лучше делать регистры, записывать туда предрасчетную информацию(даже хотябы регламентным заданием), индексируй. А потом запросы по уже подготовленным данным...
99% никакой оптимизации не делают. И в 99% она и нафиг не нужна
главная ошибка, это использование 1с как языка. каждый пишет шо хочет и в итоге получилась солянка.
А в других языках разве не так же? Везде каждый пишет шо хочет