Есть запрос под 1000 строк, выполняется около 5 секунд и это напрягает...

Выборки данных немного, все по индексированным полям, вроде все должно быть быстро,
в основном куча последующих проверок и перепроверок.
В этом запуске кроме запроса ничего не выполняется, и замер пишет что это этот запрос 97%.

Я предполагаю, что он долго компилируется, т.к. если в нем сделать синтаксическую ошибку,
то сообщение об ошибке появляется с той же задержкой около 5 секунд.

База файловая, 8.3.15, половина пользователей в тонком клиенте через веб.

Это как нибудь лечится?

не видя запрос ничего посоветовать нельзя... сохрани его  в облако, а сюда ссылку
Кому интересно - посмотрит

Удали 15, 345 И 987 строки.
Будет быстрее работать.

(0) В строке № 456 ошибка в полной бездарности написания запроса... :)

+(0) Если серьезно, рекомендую вам разобрать запрос и проанализировать его, может где не оптимально его используют.
Либо стоит рассмотреть вариант, где бы вы добавили некие регистры в конфигурацию уже с готовыми данными, что бы в запросе не проводить вычисления :)

+ И давайте уже переходите на SQL или посгрес, файловые базы в основном используются для демонстраций, либо для очень маленькой конторки, где один сотрудник на всю базу, с документо-оборотом 1 документ в год :)

Самое простое - засунуть этот запрос в ИР и выполнить пошагово, посмотришь какой шаг самый жирный

+ Есть вариант, разбить твой запрос 1000 срок, на мелкие запросики используя МенеджерВременныхТаблиц.

Или текст запроса или закрываю ветку.

(0) Оптимизирую код усилием мысли, лечу запросы по фотографии...

Как можно давать советы не посмотрев ни запрос ни план выполнения... там не parametrs sniffers?

Без понимания плана запроса сложно рассуждать о оптимизации. Так что нужно поставить примерный план запроса в голове, но для этого нужен текст запроса или выполнить и в СУБД посмотреть план запроса.

(4)(5)(6),... А чем это поможет, если 1с анализ синтаксиса производит его 5 секунд, а выполнение как следствие оставшиеся 0.н секунд?

я туплю или текста запроса нет?

(11) ну сам понимаешь, что 1000 строк - это до такой степени мизерный запрос, что про анализ синтаксиса это ты схохмил наверно, он выполняется за наносекунды. Поэтому лажа у тебя именно в тексте запроса.

Тонкий намёк на то, что в 1С запросы в принципе не умеют работать)))))

Ну возьми, например, запрос из ЗУПа, который р/л формирует. Там иногда дольше 5 секунд работает. Но там больше 2000 строк и переколбашивается вся база. Так что выкладывай текст запроса, тогда уж можно и судить

(0) А я напишу запрос в одну строку, который положит на лопатки все твои rphostы. Могу научить. Дорого.

(11) "1с анализ синтаксиса производит его 5 секунд" // Это ты про что и как выяснил? Дичь какая-то)

(16) ну может у него там ERP и запрос как раз по 1000 объектам. Пока он GUI отрисует в консоли запросов, 5 секунд и проходит, мыж не знаем.

(0) лечится что?

(0) запрос под 1000 строк листинга? Или этот запрос возвращает 1000 строк, или третй вариант?

(0) что мешает проанализировать текст запроса? 1000 строк, это не много. Работал и с запросами в 80000. Можно же все по разобрать. Слона надо есть по кусочкам, а не пытаться запихнуть сразу в глотку.

А так да, знатный вброс. Автор там хихикает сидит))))

(17) "GUI отрисует" // Так автор же вроде на время выполнения запроса сетует

(21) А в чем юмор, что бы мне хихикать то?

Вот запрос кто хотел:
https://drive.google.com/open?id=1ok9KmGsLsT4kPDVpmtVthrJFfm_CHAe9

Но смысл от этого не меняется, если делаю спициально ошибочную правку, то он висит те же 5 секунд, прежде чем начать ругаться на ошибку, т.е. эти пять секунд он пытается разобрать этот запрос. А данных там на выполнение буквально штук пять мелких документов, и все по индексам. Это анализ на ошибки одного счета и его подчиненных документов. Сделан наполовину генерационным способом.