Здравствуйте!

Необычная просьба :)

Пишу презенташку по оптимизации запросов

Нужны яркие примеры для демонстрации

Если у кого то завалялись любые сохраненные планы плохих запросов, пришлите пожалуйста!

Если сохранился текст запроса и есть пара комментов к нему, будет хорошо, но если нет - не критично

Если есть "до" и "после", то будет совсем сказка :)

Если текста не сохранилось, до и после не сохранилось - шлите as is !!!

Заранее спасибо!

PS Можно слать на  velifer .. yandex .. ru

Будешь неимоверно крут, если соптимизируешь вложенные запросы с иерархией...

(1) так их дробить на пакетные надо, как иначе-то?

ВЫБРАТЬ
Регистратор.Дата
ИЗ
ЛюбойРегистр

;)

(3) Не, ну не настолько же примитивно! ))

В УПП в процедуре расчета себестоимости фунции "сформировать текст запроса..." посмотри.

Выбрать * Из ПланСчетов.Типовой
:-)

*пардон, ошибся. Это не экстремально.
Вот так:



Выбрать * Из РегистрБухгалтерии.Типовой
Наименование зависит от страны:-)

(0)ЛЕВОЕ СОЕДИНЕНИЕ по условию <>

(8)По не равно отработает быстро. Лучше  НЕ В (&БльшойСписокНа100500 )

https://its.1c.ru/db/metod8dev#content:5842:hdoc

(9)Ну зависит от размера соединяемых таблиц еще конечно)

Я имел ввиду - может у кого завалялись сохраненные в файл планы запросов (*.sqlplan)

Ну и разумеется не совсем примитивное нечто должно быть


(9) Такой список сейчас платформа должна автоматом поместить во временную таблицу, еще в последних версиях 8.2 было

https://its.1c.ru/db/metod8dev#content:5812:hdoc:сpu_по_запросам
Там же тебе и планы будут

(13), (10)
Ага, то что там написано, в 3/4 случаев скуль прекрасно разруливает.
Или делает незначительно хуже, чем с пакетниками, поэтому яркого примера так легко не получится.

Нужна достаточно большая база и энное количество времени, чтобы воспроизвести эти проблемы. Или увидели Nested Loops и сразу паникуем?

(Ой чувствую счас холивар начнется :)))))

Я ж говорю - нужны с реальных внедрений, с достаточно больших баз файлики *.sqlplan

(3) а чем то запрос плох?
Регистратор - индексированное поле. А если обращение к реальным записям не кошерно то туча примеров из типровых..

(3) даже так
Дата + Ссылка
Эти индексы создаются всегда для любого документа. -

+(3) еще можно лучше вот так: выбрать регистратор.* ....

(15)  в типовых чтоб не обращаться к полям регистратора дата и номер есть спец регистр сведений

(0) Вот тут: http://catalog.mista.ru/public/184361/
куча примеров "плохих" запросов, с разъяснением, почему они плохие.
Например такой:

ВЫБРАТЬ РАЗЛИЧНЫЕ
    ОстаткиНоменклатуры.Номенклатура
ИЗ
    РегистрНакопления.ОстаткиНоменклатуры КАК ОстаткиНоменклатуры
ГДЕ
    ОстаткиНоменклатуры.Регистратор В(&ФильтрДокументов)

эмммм.... планы запросов зависят не только от самих запросов но еще и от структуры базы и размеры таблиц.....

в 1с практически нет средств оптимизации SQL плана запроса...

тебе чего конкретно надо?

а вообще смотри sys.dm_db_missing_index_stats и подобное, там будет тебе чего взять на презентаху...

(18) БП 3.0 последний релиз
|ГДЕ
|    ХозрасчетныйОборотыДтКт.Регистратор ССЫЛКА Документ.МодернизацияОС
|    И ХозрасчетныйОборотыДтКт.Регистратор.СобытиеОС.ВидСобытияОС = ЗНАЧЕНИЕ(Перечисление.ВидыСобытийОС.Модернизация)

а вообще глобальный поиск по "Регистратор" - развеет много сомнений...

(15) Есть интересные примеры с составными типами, но только с ними и всего :((

(22) Чисто ради интереса, что бы предполагалось изменить в этом "куске"?

(24) ВЫРАЗИТЬ по типудокумента

(0) Тогда почему именно 1С? Тут про планы запросов 1 из 10 знает. На скл.ру быстрее найдешь то что ищешь.

(26) Тут про запросы то не каждый слышал :))

Вот есть плохой, но работающий до сих пор в конторе запрос. Чем он плохой, решайте сами.

запрос1.Текст="ВЫБРАТЬ
              |    РеализацияТоваровУслугТовары.Номенклатура КАК Номенклатура,
              |    РеализацияТоваровУслугТовары.Цена,
              |    РеализацияТоваровУслугТовары.Сумма,
              |    РеализацияТоваровУслугТовары.Количество,
              |    РеализацияТоваровУслугТовары.Ссылка,
              |    РеализацияТоваровУслуг.Дата,
              |    РеализацияТоваровУслугТовары.Номенклатура.ВидНоменклатуры,
              |    РеализацияТоваровУслугТовары.Номенклатура.ВидНоменклатуры.Наименование,
              |    РеализацияТоваровУслуг.Контрагент КАК Контрагент,
              |    РеализацияТоваровУслуг.Контрагент.Наименование КАК КонтрагентНаименование,
              |    РеализацияТоваровУслуг.Склад,
              |    РеализацияТоваровУслугТовары.СуммаРучнойСкидки,
              |    РеализацияТоваровУслуг.Партнер.ОсновнойМенеджер
              |ИЗ
              |    Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары
              |        ЛЕВОЕ СОЕДИНЕНИЕ Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
              |        ПО РеализацияТоваровУслугТовары.Ссылка = РеализацияТоваровУслуг.Ссылка
              |ГДЕ
              |    РеализацияТоваровУслуг.Проведен = ИСТИНА
              |    И РеализацияТоваровУслуг.Дата >= &датанач
              |    И РеализацияТоваровУслуг.Дата <= &датакон
              |    И (РеализацияТоваровУслугТовары.Номенклатура.Родитель В (&списокном)
              |            ИЛИ РеализацияТоваровУслугТовары.Номенклатура В (&списокном)
              |            ИЛИ РеализацияТоваровУслугТовары.Номенклатура.Родитель.Родитель В (&списокном)
              |            ИЛИ РеализацияТоваровУслугТовары.Номенклатура.Родитель.Родитель.Родитель В (&списокном)
              |            ИЛИ РеализацияТоваровУслугТовары.Номенклатура.Родитель.Родитель.Родитель.Родитель В (&списокном)
              |            ИЛИ РеализацияТоваровУслугТовары.Номенклатура.Родитель.Родитель.Родитель.Родитель.Родитель В (&списокном))
              |
              |УПОРЯДОЧИТЬ ПО
              |    КонтрагентНаименование,
              |    РеализацияТоваровУслуг.Дата";

(28) всего лишь доя пяти уровней? слабаки

(28) в иерархии + по регистру надо бы, раз проведен

(28) а почему вообще до сих пор не переписали по человечески? принцип "работает - не трожь"?

(31)
да, типа того. Кстати, извиняюсь, если не правильно понял, что нужно автору. С планами запросов не знаком (

Для каждого строка из ТЗ цикл
запрос = Новый Запрос;
Запрос.Текст =
"Выбрать
| Бла-бла-бла"
|* тут Левое Соединение по условию <>;
Запрос.Выполнить().Выгрузить();
КонецЦикла;


Хуже не придумаешь

http://govnokod.ru/1c
хехе :)

(15) Есть интересные примеры с составными типами, но только с ними и всего :((

(34) За идею 5+ )))))

(0)
Все просто берешь рекомендации по написанию запросов и делаешь на оборот.

Рекомендации, кратко:
1. При использовании "ДЛЯ ИЗМЕНЕНИЙ" нужно указывать конкретные таблицы для блокировки, иначе блокировка установится на все таблицы запроса, а это избыточно.
2. Запрос должен удовлетворять структуре индексов, т.е. все поля по которым устанавливается отбор должны входить в состав индекса и без пропусков (от этого зависит что СУБД будет использовать index seek или index scan, или вообще table scan)
3. Не нужно использовать подзапросы в условиях соединения, или в ГДЕ (исключение подзапрос к временной табл.)
4. не делать соединения с подзапросами
5. не соединять виртуальные таблицы с реальными, виртуальные с виртуальными
6. не использовать ИЛИ в условиях (или <>)
7. не получать значение через точку полей составного типа

(37) Я ж писал уже об этом в (14)

(38)
"в 3/4 случаев скуль прекрасно разруливает"
а именно? Речь про подзапросы?

тру 1С ник, готовит презентацию, но планы запросов требует от других.
Возникает вопрос о качестве презентации и о ее целесообразности.

Если лень делать полноценное репро, используй хинты и будут тебе такие планы какие хочешь (оптимальные, неоптимальные)

(40) Тру 1С-ник и вообще любой Тру все делает своими руками, по 12 часов в день и без выходных.
Поэтому, да, я не Тру 1С ник )))
Поскольку часто использую аутсорсинг и помощь сообщества, для того чтобы съекономить время и ресурсы.

(0)  по планам это к профайлеру скорее . Увидите  полный индекс скан уже можете оптимизировать

(40) +Хинты не очень интересно, так как это искуственно созданная проблема. Не люблю лукавить.

Вот не хочется стоять перед людьми - "А вот еще был вот такой уникальный случай в практике" со скрещенными пальцами за спиной. Это принципиальный вопрос для меня.

(43) :) ммммм. Лучше один раз использовать хины чем переделывать архитектуры таблиц .

(43) т.е вы будете стоять перед людьми и честно говорить "А вот еще был вот такой уникальный случай в практике" и показывать чужие планы?

Принципиальность 146%!

(42) это не так... полный индекс скан иногда быстрее чем использование индексов...

я уже предлагал банально посмотреть в sys.dm_db_missing_index_stats

для начала этого хватит....