Оптимизация SQL запроса

SQL запрос выполняется слишком долго как его можно оптимизировать

SELECT concat(country.name, ', ', region.name, ', ', city.name, ', ', raion.name) AS temp
FROM mlt_adr_country country
LEFT JOIN mlt_adr_city city ON country.id = city.country_id
LEFT JOIN mlt_adr_region region ON city.region_id = region.id
LEFT JOIN mlt_adr_raion raion ON city.raion_id = raion.id
WHERE CASE 
		WHEN (SELECT * FROM (SELECT count(name) FROM mlt_adr_country WHERE name LIKE 'Россия%') as tem) > 0 THEN country.name LIKE 'Россия%'
		WHEN (SELECT * FROM (SELECT count(name) FROM mlt_adr_city WHERE name LIKE 'Теплу%') as tem) > 0 THEN city.name LIKE 'Теплу%'
		
END
GROUP BY city.id

Сейчас он выполняется 30 сек всего 200к записей
Условий будет таких же ещё штук пять Т.е. примерно запрос будет около минуты выполняться.
Как возможно его переделать

Для начала - почитать про [NOT]EXISTS подзапрос, что бы не писать бред, наподобие такого CASE, что у тебя в условиях where.

Ваяс,

Объясните словами смысл этого запроса. Его легче выкинуть и написать новый.

К сожалению я не знаю SQL. И поэтому могу написать такую чушь.
Но суть следующая
Есть форма поиска там происходит автозаполнение именно по странам, городам, районам селам и т.д.
Так сделано в ГУГЛЕ если вы зайдете на google maps и попробуете написать город или поселок то поймете о чем я говорю.
Я хочу сделать примерно так же
Когда я делаю одну таблицу например с городами которых 150 тыс данные достаются мнгновено
Но мне хотелось бы сделать вот этот сложный вариант.
Что бы например в одно и то же поле можно было написать москва или московская область или например москва ленинградское шоссе ну и соответственно он максимально близко понимал текст который впишет пользователь и вывел наиболее подходящие записи. Справочник использую КЛАДР

Ваяс
Что бы например в одно и то же поле можно было написать москва или московская область или например москва ленинградское шоссе ...

если бы, в примере запроса, вы - Россия сравнивали бы и с городами - тогда бы можно было говорить про "тупой поиск по всем атрибутам адреса"

но у вас же, почему-то, сравнивается Россия - только со странами,
а Теплу - только с городами ...
значит где-то парсите эту введённую строку, и определяете "что есть что", не так ?

qwerty112
значит где-то парсите эту введённую строку, и определяете "что есть что", не так ?

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

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

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

нуу, если говорить про "не совсем идеально", то есть "совсэм-совсэм" тупой вариант :)

SELECT concat(country.name, ', ', region.name, ', ', city.name, ', ', raion.name) AS temp
...
where concat(',',country.name, ',', region.name, ',', city.name, ',', raion.name) like '%,Россия%'
  and concat(',',country.name, ', ', region.name, ', ', city.name, ', ', raion.name) like '%,Теплу%' 

это "по любому" лучше чем ваш стартовый запрос,
но "совсем не идеально" :)

так, что считайте это так, - запрос, чисто "для поддержания разговора"

tanglir
Ваяс, чтобы определить, есть ли нужные щаписи в таблице, используйте exists().

На счет этого спасибо, я про них не знал читаю пока что.

qwerty112
это "по любому" лучше чем ваш стартовый запрос, но "совсем не идеально" :) так, что считайте это так, - запрос, чисто "для поддержания разговора"

Спасибо ) но все равно, хочется все сделать качественно, блин ведь 200 к записей это совсем не много
Почему так все тормозит, пытаюсь разобрать все эти запросы по отдельности
Уберая GROUP BY он становиться быстрее на третью часть