Привет.

Известно, что INNER JOIN производит выборку записей, которые только существуют в TableA и TableB одновременно, а так же что классический INNER JOIN можно заменить условием объединения в WHERE.

Как вижу работу ядра mysql:

1. Оптимизатор mysql выбирает основную таблицу (например, TableA) и начинает построчно сравнивать со второстепенной таблицей (TableB).

2. TableA, TableB - могут не совпадать с физическими таблицами, а сами могут быть полученными в результате различных сортировок и могут быть "почти" каждый раз уникальными.

3. Таким образом мы имеем два множества строк, одно из множеств берется за основное и начинает построчно сравниваться со вторым.

4. Хорошо бы, чтоб связующее поле было проиндексированно.

Собственно вопрос:

Есть ли способ не делать сравнение построчно? Как-нибудь объединить два множества, чтоб получить результат пересечения по ключу? Если не запутано объяснил могу еще попытаться на каком-нибудь примере показать.

Короче не нравится, что идет перебор строк во второй таблице. Хочется как-то это ускорить.

Спасибо.

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

Кроме индексов вы ничего не ускорите. При грамотно расставленных индексах будут сравниваться только то количество строк которое соответсвует индексу.
Ну и первым пунктом я бы написал обработку условия WHERE если оно отсутсвует, то все остальное. Хотя я тут как-то пошутил, что как оно там внутри работает не знают даже сами разработчики MySQL (а по аналогии и всех остальных СУРБД) слишком уж там мудреный алгоритм оптимизаторов и улучшайзеров и два казалось бы одинаковых запроса могут работать по разному.

_____________
Стимулятор ~yoomoney - 41001303250491

Valick
Спасибо.

Интересно вот еще что, когда две таблицы готовы для сравнения и объядинения они для MySQL типа как одна? Ну как бы в памяти их искомые столбы сливаются что ли?

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


_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

INNER JOIN делает своё дело. Отличие в том что оптимизатор в таком запросе в основном начинает по первичным ключам связываться хорошо и индексам. То есть от других join отличается улучшенным агрегированием по первичным ключам и индексам.

INNER JOIN оставляет MySQL возможность выбора порядка объединения оптимизатору, он может выбрать более оптимизированное объединение.
LEFT JOIN нужно вручную расставлять таблицы в оптимальном порядке и ставить индексы в оптимальном порядке слева-направо (WHERE pk, i1, i2 ....).
EXPLAIN в помощь )

Guest

Да но...я уже тестил как раз обычный INNER JOIN подойдет потому, как от сортировки зависит какой по размеру будет таблица левая или правая.

Test for Chrome: work?

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.