Как оптимизировать SQL запрос?

Question

[IdFox]

Всем привет

Подскажите, нужно ли оптимизировать SQL запрос в плане нагрузки на сервер?
Или он нормально составлен и так и должен выполняться?

Имеем две таблички
numbers - например список телефонных номеров
numbers_type - категории, присвоенные каждому номеру (их может быть несколько)

Задача
Выбрать из numbers номера с определенными категориями (несколько)
Пишем запрос

SELECT * FROM `numbers` WHERE `number` IN (
SELECT `number` FROM `numbers_type` WHERE `type` IN (1, 3, 5)
)

У меня вопрос
Вложенный запрос возвращает большое количество записей
Ну например 50 000 шт
Потом эта результирующая выборка попадает в основной запрос
Не знаю как правильно сказать - MySQL это нормально переваривает?
Или лучше как-то сделать другую структуру табличек, чтобы запрос легче выполнялся для сервера

Спасибо за ответы

Answer 1

[Andrey Tsvetkov]

Мне кажется у вас тут будет лучше работать JOIN

SELECT 
	*
FROM 
	`numbers` A 
	LEFT JOIN `numbers_type` B ON A.`number` = B.`number` 
WHERE 
	B.`type` IN (1, 3, 5)

Comments

[IdFox]

Так тоже думал делать
Но возможно не хватает знаний в SQL
На выходе, если номер в 2х категориях положим, то и результирующих записей получим две
А нужно одну :)
Можно конечно через DISTINCT в первом запросе, но нужно помимо самого номера и все его остальные данные (поля первой таблички)

[Andrey Tsvetkov]

GROUP BY A.`number`

[IdFox]

Andrey Tsvetkov, супер!
А еще можно что-то вроде строки из объединенных type через запятую
Или это фантастика уже?
Ну т.е доп. столбец где все type для этого number перечислены через запятую

[Andrey Tsvetkov]

SELECT 
  *,
  GROUP_CONCAT(B.`type`, ", ") AS `types`
FROM 
  `numbers` A 
  LEFT JOIN `numbers_type` B ON A.`number` = B.`number` 
WHERE 
  B.`type` IN (1, 3, 5)
GROUP BY A.`number`

[IdFox]

Andrey Tsvetkov, ОГРОМНОЕ спасибо
Как бы все знать где и что искать...
Понятно, что Google молодец, но нужно знать, что искать
В общем еще раз спасибо!

[Andrey Tsvetkov]

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

Answer 2

[alex-1917]

50к - мизерная выборка, забей!!))
если проект на вырост, тогда не забивай!!))

В твоем варианте смешная выборка, не видел ты 10 этажных джойнов, коллега!!...

И еще - не забывай, что БД ВСЕГДА хранится на диске, а в памяти она появляется уже потом)))! отсюда выход для некоторых огромных запросов - быстрее вопрос решается обработкой не в БД, а на приложении.
Если кратко, то делаешь выборку ВСЕХ твоих номеров без условий - для БД это самая непрожорливая операция, по сути два мгновения, далее выборку в массив и уже на сервере разбираешь чо и как, через тот же php. Проверено на выборках 20М-300М - - скорость фильтрации на два порядка больше, если это дело поручать приложению!

Answer 3

[Barmunk]

Как насчет join? То что у вас очень странно выглядит.

50 тысяч это не много.
in имеет лимиты https://stackoverflow.com/questions/1069415/limit-...

Answer 4

[Dimonchik]

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

когда юзаешь where in - то результат IN мускулю тоже приходится держать в памяти, но прочекать при этом придется минимум только те что в where, а при неудачном оптимизаторе - всю таблицу, а при очень неудачном - еще и не один раз

проще говоря, "where in" всегда медленнее join, по сути - это синтаксический сахар для разовых запросов
если и кажется быстрее, то на небольших сетах, где на join больше накладных расходов