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

Есть ли куда оптимизивать запрос? Если есть то как?)

(0) Долго работает?

(1) Сам запрос нет, но он у меня в цикле (делается закрытие доков по фифо). Так вот выбираются записи в три раза дольше чем записываются через НаборЗаписей.

напиши измерения регистра с порядком как в базе

(2) Вот и вынеси его наверх и будет тебе оптимизация.

Измерения
--Документ (индексировать, тип составной)
--Партнер (не индексировать, тип справочник)
Ресурсы
--Сумма

(4) Это ж документы, которые закрываются по ФИФО, как я его вынесу, у меня голова лопнет...

(6) От дерева с одним уровнем еще ни у кого не лопнула.

(6)
Если &Дата в цикле всегда одинаковое значение, то нужно выносить из цикла.

Как минимум можно оптимизировать в параметрах обращения через точку -
Док.Ссылка.
Док.Партнер

(7) т.е. с двумя. Опять от нуля подсчитал))

Просто проверь, не будет ли быстрее если отбор по партнеру и документу убрать из параметров. Учитывая, что результат джоина линкуется с таблицей документов (Документ.Дата) почти наверняка будет.

(8) Разное, в зависимости от документа. Я их массово перепровожу. 85000 доков -два дня перепроводятся. Нужно чтоб в ночь укладывались

(5) плохо для оптимальности что документ у тебя первым измерением и ты отбираешь по неравенству - индекс скорее всего не будет использоваться в сочетании с условием по партнеру

ВзаиморасчетыОстатки.Документ.Дата - там документы одного вида? Иначе вызывается неявное левое со всеми типами.
Если массовая обработка, как вариант - убрать цикл и сделать временной табличкой собирать нужные документы, после этого считать

ВзаиморасчетыОстатки.Документ.Дата - если Документ составного типа, то будет тормозить из-за неявных соединений.
  
Порядок измерений вызывает сомнения. Кажется, в практике чаще нужны остатки расчетов с выбранным партнером по всем документам, чем наоборот. Здесь, кстати, пример подтверждает это.
  
Отбор по непустому документу - тоже странный. Кажется следствием плохо продуманной архитектуры. Здесь лучше изменить логику конфы, чтобы не было в регистре пустых документов. Если невозможно - то отсекать остатки с пустыми документами при постобработке.

Вот скрин проблемы http://savepic.ru/13524575.png
(15) Пустой документ получается когда идет предоплата, в этот момент еще не ясно какой док. отгрузки закрывать

(14) тип составной

сделай уже ФИФО прямо в запросе

(5) поменяй местами партнер и документ

(16) 0.74% - это проблема????

(20) да, в итоге две секунды на документ

(21) а больше всего что занимает?

или 0.74% = 2с, тогда 100% = 250с?
У вас документ проводится 250 секунд?

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

(24) так и делаю

(0) Пересчёт итогов делал?

(25) Считай фифо сразу в запросе. Вот тут методика описана
http://catalog.mista.ru/public/68225/

(27) да это не обычное фифо, у меня есть приход денег в момент, когда еще нечего закрывать (преоплата), потом отгрузки сами себя по фифо закрывают

Вопрос снят, основное время затрачивалось на вызов сервера для отображение состояния выполнения:
Состояние("Проводим "+Стр.Док+"",(тек*100)/всего,"Номер док "+тек+"");
Теперь 0,10 сек. на документ

(29) Оборжаться :)

(29) Наберут на работу невменяемых любителей писать запросы в цикле, а потом ноют, что у них все плохо.

(31) заметьте, он запрос из цикла так и не убрал...

(32) а зачем, если на 1 документ - 1 запрос

да уж...