Поработав некоторое время с SQL Server и Access, начал осваивать MySQL и споткнулся буквально на пороге: пытка сделать inner join двух идентичных таблиц по 200 000 записей в каждой, отправляла MySQL в нокаут (результатов ни разу не дождался). Наконец меня осенило сделать им индекс, в точности соответсвующий условиям join'а и дело пошло.
Т.е. получается, что для MySQL желательно создавать специальные индексы для каждого JOIN и WHERE, дабы дать ему инструмент поиска нужных записей отличный от полного перебора?

С другой стороны Access, откуда как раз и приехали в MySQL 2 упомянутые таблицы, справлялся с задачей за 3 секунды, и его, похоже, не напрягало, что условия JOINа не совпадали с основным ключем (join был по части полей основного ключа и нескольким неключевым полям). В SQL Server я тоже никогда не занимался созданием индексов и проблем с производительностью не испытывал (возможно, благодаря мощному серверу на котором он стоит).
Чего такого умеют Access и SQL Server, чего не умеет MySQL? Получается, что первые сами строят всевозможные индексы, а MySQL оставляет это на совести пользователя?

lockyМаксим М.,
например, они могут уметь делать не только loop join, но и hash join и merge join.

Я имел в виду неочевидные особенности работы с индексами при переходе с Access на MySql.
Сейчас я уже потихоньку привыкаю к тому, что если хочешь ускорить работу joinа - надо сделать ему индекс по соответствующим полям, иначе mysql будет делать декартово произведение с последующим его полным перебором. В этом свете становится совершенно непонятным, как Access справляется с join'ами без явного указания индексов?