Вроде вопрос простой, но хочетсяуточнить механизм...

Есть Таблица1 и таблица2. Выбираем запросов данные из Таблица1 и левым соединением цепляем к ней Таблицу2. Ну например:

Выбрать
  Таблица1.Реквизит1,
  Таблица2.Реквизит1

Из Таблица1 как Таблица1
Левое Соединение Таблица2 как Таблица2
По Таблица1.Реквизит1 = Таблица2.Реквизит1

Итак, вопрос - каким образом будет формироваться выборка из таблица2? Т.е. Из нее возьмутся ВСЕ данные (получим большую таблицу), а потом на эту таблицу будут накладываться ограницения "ПО"....или первоначальная выборка данных из таблицы2 будет изначально формироваться с отбором (т.е. сразу с ограничением) ?!?!?!

(0) зависит от размера таблиц. Может сперва отобрать все записи из таблицы 1, а потом наложить отбор на таблицу 2, а может и наоборот.

(0)Щас тебя в профайл отправят

это уж как оптимизатор решит

(1) это как? два алгоритма в зависимости от размера? и какой пороГ!

вротмненоги...
LEFT OUTER JOIN

Оператор левого внешнего соединения LEFT OUTER JOIN соединяет две таблицы. Порядок таблиц для оператора важен, поскольку оператор не является симметричным.

Заголовок таблицы-результата является объединением (конкатенацией) заголовков соединяемых таблиц.

Тело результата логически формируется следующим образом. Пусть выполняется соединение левой и правой таблиц по предикату (условию) p.

   В результат включается внутреннее соединение (INNER JOIN) левой и правой таблиц по предикату p.
   Затем в результат добавляются те записи левой таблицы, которые не вошли во внутреннее соединение на шаге 1. Для таких записей поля, соответствующие правой таблице, заполняются значениями NULL.

(3) аналогичнй вопрос...и как он может решить? в зависимости от чего?

(4)>(3) оптимизатор решает всё, на него влиять ты можеш только косвенно, например обновляя статистику СКЛ, и писать грамотные запросы

ну ладно не знаешь, но поискать бы хоть попробовал

(4)насколько я понял, 1сина сама строит скульный запрос так как считает более оптимально. А как по ее мнению оптимально это даже Нуралиевы не знают

(4) это (3). порог.. а хз... тут уже SQL работает (а это (2))

(8) ты есть, нафиг искать ещё

(9) нене... одинесина как раз таки транслирует запрос один в один, а вот скульный оптимизатор уже и решает, как оно лучше...

если есть индекс на т2 по реквизит 1 то будет индекс сик

если нет индекса, то тэйбл скан

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

(5) вообще-то ,то что ты вывалил совершенно не отвечает на мой вопрос! так что сумничить не получилось у тебя

вот... для затравки http://msdn.microsoft.com/ru-ru/library/ms190623(v=sql.105).aspx

(15) еще один умник. Не поверишь наверное, но знаю

(18) нафига тогда спрашиваеш? это всё смотрится в профайлере, и про оптимизатор чего спрашиваеш?)

(19) спросить здесь было быстрее

(0) На этот вопрос ответит анализ плана запроса (в 1С - нету MS SQL).

(19) он ведь в (5) действительно не ответил на вопрос...фраза

"Тело результата логически формируется следующим образом. Пусть выполняется соединение левой и правой таблиц по предикату (условию) p."

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

(22) В зависимости от используемой базы данных "когда и как именно" может иметь разительные отличия. Поэтому относить к этому как к "черному ящику"

(22) ответ в (1)(2)(3) же, или мы телепаты оптимизаторов скульных? много критериев, зависит от конкретной БД

Понятно. Всем спасибо!

Можно вклиниться в высокоумную беседу? Спасибо! ))
Из темы вытекает такой вопрос: есть общая рекомендация не делать левых соединений с (ВЫБРАТЬ...), а сначала из второй таблицы отобрать во временную и соединять уже с ней. И для того, чтобы понять пользоваться этим советом или нет в каждом конкретном случае нужно знать, что сначала, как спрашивает автор: полная выборка или условие связи. Потому как если первая таблица имеет десятки строк, а вторая таблица имеет миллион строк, а по условиям связи нужна одна для каждой из первой, то имхо как-то неоптимально выбирать весь миллион во временную.
Прокомментируйте плиз.

(26) это и послужило причиной вопроса. +

(0)это в любом случае декартово произведение 2-х табличек + выборка с помощью элемента ON + "добавление внешних строк"

настоящий кодер сам управляет условием выборки и соединением

(29) ты просто нереальный кодер ) респект тебе и уважуха! Да будет у тебя зп от 100500 и прекланяются перд тобой все Нуралиевы! Ты просто мега чел!

(30) милионы пафоса детектед

(0) кури оптимизатор конкретной субд на которой стоит 1с

(32) ну давай курить вместе 2 самых распространеннх варианта:

1) Файловая база
2) Базана MS SQL

(33) версии MS SQL тоже сильно отличаются

Пообщался с нашими SQL-ками. Ответ такое: если нужно получить стабильно удовлетворительный результат - то все сначала во временную с индексами по полям связи и потом джойн с ней. Если хочется получить оптимальный результат - то смотреть как индексы построены, и далее отдавать все на откуп оптимизатору SQL. Потому как оптимизатор SQL может работать совершенно по разному в зависимости даже не от версии SQL, а от определенного сервис пака. И получится, что запрос, который ты оптимизировал под один сервиспак и увидел по нему оптимальный план, на другом сервиспаке будет иметь абсолютно другой план.
Вот как-то так

(33) Для файловой базы однозначно сначала выборка, потом условие.

(35) а точ, что от больших временных темп у базы пухнет, эт ничего?

(37) Теже SQL-щики привели пример, который видели собственными глазами: здоровенный запрос, куча джойнов с селектами, в плане запроса оптимизатор сам создал несколько временных таблиц.