Если я получаю данные, допустим  табличной части Товары РТУ по конкретному документу
и потом мне нужно присобачить другую таблицу с соединением по ссылке, например

Выбрать Товары.Номенклатура,ВТ.Статус из Документ.РТУ.Товары Как Товары Внутреннее соединение Регистрсведений.Статусы Как ВТ по Товары.Ссылка= Вт.Документ где Товары.Ссылка=&СсылкаНаМойДокумент
собственно, никогда не задумывался. а стоит еще в условии дописывать: по Товары.Ссылка= Вт.Документ  И вт.Документ = &СсылкаНаМойДокумент. Будет ли  в этом случае запрос оптимальнее или на таком объеме нет? и вообще отбирает ли скуль записи перед тем как соединить по условиям соединения или нет?

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

Если тема интересна, погугли "план выполнения запроса". У скуля есть инструментарий для анализа реального алгоритма выполнения запроса. Есть куча статей (и в применении к 1С в частности), как его "читать". Собственно, это часть знаний необходимых "эксперту по технологическим вопросам".

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

(3) Вот навскидку: http://catalog.mista.ru/public/877736/

(4) статья печальна и стереотипна.

(4) по ней и разбираюсь, но много непонятного.

(5) а чего печальная?

(7)
1) nestedloops обкакали зазря.
2) tablescan-ов в 1с почти не бывает (только когда ВТ).
3) indexscan также плох, как и tablescan, но clusteredindexscan еще хуже.

дальше не читал, дальше статистика пошла, там ничего нового.

2) "tablescan-ов в 1с почти не бывает (только когда ВТ). " - вместо него clusteredindexscan

(8) "indexscan также плох, как и tablescan" это в том случае, когда ты не попал в сортировку.

(8) а можете посоветовать что то почитать о планах запросах с детальным описанием всех сканов и прочих операторов

(11) + с расчетом на нубов.

(11) Нет такого. Не находил.
Просто возникает что-то непонятное, ищещь в инете, как правило, англоязычном, а там - хоба - ссылка на Мелкософтовский сайт с описанием причины.
Как пример:

ВЫБРАТЬ
РТУ.Дата,
РТУ.Номер
из Документ.РТУ как РТУ

посмотрите на план запроса на большой базе и удивитесь.