Имеет ли значение в современных СУБД (в частности MySQL) порядок

← →
VictorT © (2005-07-07 18:06) [0]

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

← →
Polevi © (2005-07-07 18:09) [1]

если бы он еще всегда правильно решал

← →
VictorT © (2005-07-07 18:12) [2]

> если бы он еще всегда правильно решал

И всё-таки, для него есть значение, как написан запрос?

← →
rayrom © (2005-07-07 18:16) [3]

Порядок имеет значения от важного к мене важному если используются связи или от большего к меньшему (иеется в виду количество записей в таблицах), но сейчас это не совсем актуально, просто ты можеш проверить как работают твои запросы если менять местами таблицы в предложении from, и условия where.
Для етого есть специальная конструкция, вот выдержка из мана:
Синтаксис оператора EXPLAIN (получение информации о SELECT) EXPLAIN имя_таблицы или EXPLAIN SELECT опции_выборки EXPLAIN имя_таблицы является синонимом операторов DESCRIBE имя_таблицы и SHOW COLUMNS FROM имя_таблицы. Если оператор SELECT предваряется ключевым словом EXPLAIN, MySQL сообщит о том, как будет производиться обработка SELECT, и предоставит информацию о порядке и методе связывания таблиц. При помощи EXPLAIN можно выяснить, когда стоит снабдить таблицы индексами, чтобы получить более быструю выборку, использующую индексы для поиска записей.

← →
VictorT © (2005-07-07 18:23) [4]

> от важного к мене важному

что такое "важный"?

← →
VictorT © (2005-07-07 18:30) [5]

Были такие рекомендации:

О порядке именования таблиц в предложении FROM

В зависимости от способа считывания оптимизатором операторов SQL порядок, в котором таблицы перечислены в предложении FROM запроса, может оказывать определенное влияние на его выполнение. Например, наиболее выгодным может оказаться такой порядок именования таблиц, когда сначала перечислены таблицы меньшего размера, а затем большего. Многие опытные пользователи хорошо знают, что размещение в предложении FROM таблиц наибольшего размера последними приводит к более эффективному выполнению запроса.

О порядке задания условий соединения таблиц

Для соединения таблиц, имеющих один или несколько общих столбцов, часто используются так называемые основные таблицы. Основной мы называем главную таблицу запроса, с которой соединяется большинство или даже все другие таблицы. Обычно столбцы основной таблицы помещаются в предложении WHERE справа от операции соединения. Таблицы, соединяемые с основной таблицей, как и в случае предложения FROM, обычно указывают в порядке возрастания их размеров - от самой маленькой до самой большой.

При отсутствии в запросе основной таблицы все другие таблицы следует именовать в соответствии с их размерами - от наименьшего к наибольшему. При этом в предложении WHERE поля из таблиц наибольшего размера следует помещать справа от операций соединения, а условия соединения указывать прежде условий фильтрации.

Наиболее ограничивающее условие

Наиболее ограничивающие условия, как правило, оказывают существенное влияние на эффективность выполнения запросов SQL. Так что же это такое - наиболее ограничивающее условие? Наиболее ограничивающим называется такое условие предложения WHERE запроса, в соответствии с которым возвраща-ется наименьшее число строк данных. И наоборот, наименее ограничивающим является условие запроса, возвращающее наибольшее количество записей. В этой главе мы сосредоточим свое внимание на наиболее ограничивающих усло-виях только потому, что с их помощью отфильтровывается наибольшее коли-чество данных. При написании операторов SQL все ваши усилия должны быть направле-ны на то, чтобы оптимизатор первым оценивал именно наиболее ограничива-ющее условие, поскольку в этом случае возвращается подмножество данных наименьшего размера, что, в свою очередь, приводит к уменьшению непроиз-водительных затрат, связанных с выполнением запроса. Естественно, что дей-ственное размещение в запросе наиболее ограничивающего условия требует от вас понимания того, как работает оптимизатор. Наш практический опыт го-ворит о том, что во многих реализациях оценка оптимизатором предложения WHERE начинается с самого последнего условия. Следовательно, для того, что-бы оптимизатор мог начать свою работу именно с наиболее ограничивающего условия, вы должны поместить его в предложении WHERE последним.

Имеет ли смысл их сейчас ещё придерживаться?

← →
rayrom © (2005-07-07 18:30) [6]

В связке главный - подчиненный, а по EXPLAIN почитай на www.mysql.ru, там есть дока на русском я тебе только часть кинул, там подробнее!

← →
rayrom © (2005-07-07 18:34) [7]

Поэксперементируй через EXPLAIN, тогда точно узнаеш!

← →
DiamondShark © (2005-07-07 19:40) [8]

А что, "Современные СУБД"(тм) оператор join уже не поддерживают?

← →
VictorT © (2005-07-08 10:00) [9]

> DiamondShark © (07.07.05 19:40) [8][Ответить]

Как-то так сложилось, никогда не пользовался.
Т.е. вот это хорошая рекомендация?
При записи инструкций SELECT пользуйтесь оператором JOIN для создания обьединений, а не операторами сравнения в предложении WHERE. Это позволяет легко
определять, какие выражения задают правила объединения таблиц, а какие — ограничивают число записей в таблице результатов запроса.

← →
Polevi © (2005-07-08 10:32) [10]

ты join на русский язык переведи

← →
Danilka © (2005-07-08 10:40) [11]

в Орокле оператора join нет. :)

← →
evvcom © (2005-07-08 10:45) [12]

> Т.е. вот это хорошая рекомендация?

Имхо, хорошая. Во всяком случае используя join тебе доступны следующие вариации: inner, left, right, full, cross. Может что-то в MySQL из этого и не реализовано, но в стандарте это есть. Тогда как в where эти вариации либо отсутствуют (наверное), либо ограничены.

> Во всяком случае используя join тебе доступны следующие
> вариации: inner, left, right, full, cross. Может что-то
> в MySQL из этого и не реализовано

Смотря какая версия!

> Смотря какая версия!

Эт-точно! (с) Сухов

По-моему это прописано в стандарте SQL-92, а то, что это не реализовано в некоторых версиях даже "самых уважаемых" серверов, конечно, не есть хорошо.

> Т.е. вот это хорошая рекомендация?

Хорошая.

> Смотря какая версия!

Глянул, как минимум несколько последних поддерживают.

Имеет ли значение в современных СУБД (в частности MySQL) порядок Найти похожие ветки