polgerПробовал всё это соеденить джойнами но сервер не переварил такую большую кучу.Как именно пробовали?
В лимит в 61 джойн не уложились?

polger,

Вариант через подзапросы в секции SELECT тоже пробовали?

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

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

polger Вот объясните знатоки, почему такая разница во времени исполнения? Разницу между INNER и LEFT я понимаю, мне как раз и нужно, что бы в результате были все пользователи не зависимо от заполненности данными.В INNER оптимизатор волен выбирать любой порядок соединения таблиц. При 50 джойнах возникает 51! комбинаций последовательности таблиц. Это явно слишком много и оптимизатор скорее всего выбирает не тот вариант.
А при LEFT порядок соединения таблиц всегда четко определен, ведущая слева. И оптимизатору просто не остается пространства для неверного выбора.

polgermiksoft,

Если я не ошибаюсь в синтаксисе, пишу с телефона по памяти, то у меня примерно следующее:
SELECT cit.value, cou.value
FROM users u
INNER JOIN table_city cit ON u.city = cit.id
INNER JOIN table_country cou ON u.country = cou.id
... И так 50 раз
Не правильно?
Запросы выполняю в phpmyadmin
В таблице users 20 000 тестовых записей.Еще должно быть условие на таблицу users в секции WHERE, иначе это будет выборка всех пользователей с огромными затратами.

polgerВопрос ко всем: Будет ли мной вышесказанное означать, что когда количество данных удвоится, то и удвоится время обработки этого запроса?Нет, при правильной индексации время выполнения такого рода запросов растет примерно логарифмически (пока хватает всяких кэшей и буферов.) относительно количества данных, что значительно медленнее, чем линейно.

schiОткуда взялось 51! ?Количество перестановок .

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

schiНе будете ли так любезны ткнуть ссылкой в описание оптимизатора, который работает описываемым вами образом ?Не совсем то, но близко:
http://dev.mysql.com/doc/refman/5.7/en/left-join-optimization.html The join optimizer calculates the order in which tables should be joined. The table read order forced by LEFT JOIN or STRAIGHT_JOIN helps the join optimizer do its work much more quickly, because there are fewer table permutations to check.

Кстати, там же есть важный момент, про который часто забывают:
http://dev.mysql.com/doc/refman/5.7/en/left-join-optimization.html For a LEFT JOIN, if the WHERE condition is always false for the generated NULL row, the LEFT JOIN is changed to a normal join. For example, the WHERE clause would be false in the following query if t2.column1 were NULL:

Therefore, it is safe to convert the query to a normal join:

This can be made faster because MySQL can use table t2 before table t1 if doing so would result in a better query plan.

schimiksoftНе совсем то, но близко:
...


Видимо я неудачно выразился. Я бы хотел увидеть подтверждение, что для соединения N таблиц оптимизатор MySQL всегда будет выполнять (N+1)! попыток соединить таблицы в разных сочетаниях.Ну непосредственно (N+1)! он не будет пытаться перебрать, ибо на этого никакого времени не хватит, это лишь теоретический предел.
Оптимизатор будет перебирать до некоторого своего предела. В Оракле он настраивается, насколько я помню, а в MySQL такой настройки я не нашел.
Оптимизатор так же учитывает наличие индексов и старается строить план так, чтобы их использовать.

См. также http://dev.mysql.com/doc/internals/en/optimizer-joins-access-methods.html

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

P.S. Хотя, возможно, мы это все перемудрили, а в запросе просто какая-то банальная ошибка :)
Мы же полного текста запроса и его плана не видели.

alex564657498765453Так что, берём на веру что ничего менять нельзя и мучаемся как быстро склеить 50 таблиц?Зачем мучаться-то? Помогаем оптимизатору (указанием LEFT или STRAIGHT_JOIN) и едем дальше.